Question If HTML is stateless, how do web apps such as document editors (google docs, word365, etc) maintain their full dataset?

[sao123]

Back story... at my work, we have several large XML configuration files which associate items along with costs, which can be used when building a CADD file to take estimate the quantity of material used within the drawing to give out an estimated cost of the entire build.
One of the things we have to do frequently is update the item costs in the XML file, because construction costs (stone, concrete, blacktop, fill, etc) fluctuate almost weekly.

So I had set out to make a document editor in C# Webforms which would be used to more quickly edit the needed values, without having to scroll thousands of lines in a text editor.

Currently, I have the following functionality.
Select and Load an XML text file document.
Read and parse the document.
For Each CostRatio element or UnitCost+Unit element pair, Dynamically
Create a Label with the Material Name and CodeDesignation,
Create an Editable TextBox for Cost Ratio or 2 Editable textboxes for UnitCost and Unit,
Create A Save Button for that row.

The user could then make a change to a the values and click the button in the row which would then update the XDocument,
And eventually Save the file back into the original XML document or a new copy.

So my problem is between page load and Data Change Save, since HTML is stateless, the XDocument object does not persist between events.
Now I know I can session the document and it could be editable for a short time up to timeout... but that seems like a terrible solution.

How do document editors such as google docs and microsoft word 365 online have doucment data that persists between postbacks without maintaining an active server side connection?
WebApp Document Editors seem to have a mythical state which isnt supposed to exist...

Is there a hidden client cache control I am missing?

The operations of Document Editors seem too slow for a database, and with so many simultaneous users and documents, that would seem an impossibility?
What am I missing.

 

[sao123]

You say that the file that is open exists on the local machine.

Correct

But right above you say it does not reside on the local machine itself.

The web application needs the ability to do IO Operations on the client using the C# System.IO library... IT does not reside on the local machine itself.

Statement was referring to the code and IIS Components. Neither the ASP.net CODE nor .Net Framework nor IIS are on the local machine. They are on the server.
There is a difference between the application and the data file it is processing/consuming...
The user interacts with the code via a browser same as every other web page on the planet.
The file is on the client. The operation happens to a file on the client. The C# is NOT on the client.
I dont know how many ways I can say this.

But I thought it was never on the server and was all local?

This is all Stream IO Operations...

The file exists on the machine as a physical file on the C drive.
Its contents are read and placed into a Stream Object. The Stream Object is transmitted to the server via a http transaction.
The Stream Object is loaded into XDocument Object.

The file itself is never physically transferred or copied to the server file system at any time... it is read and transmitted as binary data and populated into objects.

if (XMLInputFile.HasFile)
{
    if (XMLInputFile.PostedFile.ContentType == "text/xml")
    {
        using (Stream FS = XMLInputFile.PostedFile.InputStream)
        {
            XDocument XMLDoc = new XDocument();
            XMLDoc = XDocument.Load(FS);
            XNode FirstParent = XMLDoc.FirstNode;
            .
            .
            .
        }
    .
    .
    .
    }
.
.
.
}

You also talk about postbacks, which I am assuming is a POST made to the backend.

A postback is any get or put request generated to the web server.

Then you say this...

The file I read in is no longer in the server memory when it is time to do the save.

Here you are splitting hairs again with terminology......Its not the file, its the binary contents of the file previously stored in the Stream and XDocument Objects... and yes, they no longer exist.
This concept can be demonstrated very simply with 10 lines of basic code. If you compile the below code and put the ASPX and DLL into IIS and browse to the page from a browser, what will be the result which ends up in the textbox when button1 is clicked?

Webform1.ASPX

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="WebForm1.aspx.cs" Inherits="WebApp1.WebForm1" %>

<!DOCTYPE html>

<html xmlns="http://www.w3.org/1999/xhtml">
<head runat="server">
    <title></title>
</head>
<body>
    <form id="form1" runat="server">
        <div>
            <asp:Label ID="MyLabel" runat="server" Text="MyTextBox"></asp:Label>
            <asp:TextBox ID="MyTextBox1" runat="server"></asp:TextBox>
            <br />
            <asp:Button ID="Button1" runat="server" Text="Button" OnClick="Button1_Click" />
        </div>
    </form>
</body>
</html>

Webform1.ASPX.cs

using System;
using System.Web.UI;

namespace WebApp1
{
    public partial class WebForm1 : System.Web.UI.Page
    {
        int X;

        protected void Page_Load(object sender, EventArgs e)
        {
            if ( !Page.IsPostBack )
            {
                X = new int();
                X = 3;
            }
        }

        protected void Button1_Click(object sender, EventArgs e)
        {
            MyTextBox1.Text = X.ToString();
        }

    }
}

If you believe that 3 is what will end up into the textbox you are incorrect.
The int X object ceases to exist as soon as the page is loaded. Even though the Page is in the users browser... It does not exist upon pressing the button.

 

[sao123]

I can't help with the IsPostBack/object persistance question because I only do database stuff in the past using Grid, Fields, textbox etc.

But I can say that you CAN'T use System.IO on server or browser to write file on the client machine (you can only use it on server), that's all browsers that in the past few decades trying to fix/avoid, it's security holes that hackers love to use. You can only download file through http or https.

Yes, I can. The system.IO Part is already working... It works, its done. It loads. It saves.

I also don't understand this

If it's already working, why do you need System.IO to work? You again were contradicting yourself.

Read my previous message to understand the problem better.



I read the file and use it to populate the text boxes.
The Stream & XDocument objects cease to exist.

User edits the data in the text boxes in the browser and presses the save button.
At this point my XDocument object does not exist... I have to RE-READ the file into a steam and RE-POPULATE the XDOCUMENT object again before I can overwrite the values in it with the new ones from the Text Boxes.
The XDocument values are overwritten and the document is converted back into a Stream Object and the file is written back to the local machine file system.


I dont want to have to re-read the file from the users file system every time the save button is pressed. The XDocument Object... needs to be cached somewhere.

 

[purbeast0]

Okay you officialy lost me when you said a postback is a request generated by the server. Server's don't generate requests they generate responses to requests that the clients make. So either you are just wrong/mistaken or this MS technology is completely going against any types of standards.

It seems really silly that you would upload a document to the server only for it to send it right back.

I'm not sure why you keep thinking that the "document" and the "binary data of the document" are different. A document is binary data.

All of this proprietary crap is EXACTLY why using MS stuff for web apps is never a good idea.

 

[sao123]

Okay you officialy lost me when you said a postback is a request generated by the server. Server's don't generate requests they generate responses to requests that the clients make. So either you are just wrong/mistaken or this MS technology is completely going against any types of standards.

Please re-read what was written... a postback is a request generated TO the server. Nowhere did I say BY
postback = HTTP PUT or HTTP GET or JAVASCRIPT _DOPOSTBACK()

A Server CAN make http requests to itself. -> Cascading Dropdowns...
User selects a value in the first dropdown. The server makes an AJAX call to itself to set the list of items into the second dropdown based on the choice now selected in the first.

It seems really silly that you would upload a document to the server only for it to send it right back.

There are many reasons for uploading document data and then eventually sending it back. All of them involve some processing operation to be done on the document prior to send it back...
Things like editing/modification, processing, scientific calculations, extraction, or verification/correction of the document... It could be controlled by the user or automated operations.
(I could list thousands of possible ways to apply this....... upload a text document of homework and get it back graded... upload a text document and get it back spell/grammar checked... upload a text document get it back checked for plagiarism... upload some mathematical calculations get back the answers... upload a image of a check and get the money deposited and get the cashed check back)

The web is not simply a collection of pages for you to browse and read. There is a lot of data processing which is done based on file IO...

I'm not sure why you keep thinking that the "document" and the "binary data of the document" are different. A document is binary data.

They are different where and how they are stored and accessed? They are both binary data but have a completely different structure.
A document is a file saved to disk in the file system... A C# Stream Object is not on the disk. It is a buffer which exists with the Memory Heap.
A stream object does NOT have a file system header, it is RAW data. You cannot see a Stream Object in your File Explorer...
A file on disk is not accessible by memory pointer operations, you cannot go through through it with a foreach loop.

All of this proprietary crap is EXACTLY why using MS stuff for web apps is never a good idea.

Streams are hardly proprietary to Microsoft, considering they were created in 1984 by Bjarne Stroustrup for C++ code.
C++, C#, PHP, Python are just as viable for data processing as current Javascript.

Actually they are a very good idea...
The thing nice about .NET Web Forms means just about anything you can do in a windows forms application or a console application, you can also do in a web application. You just have to stop being so closed minded.

 

[purbeast0]

There are many reasons for uploading document data and then eventually sending it back. All of them involve some processing operation to be done on the document prior to send it back...
Things like editing/modification, processing, scientific calculations, extraction, or verification/correction of the document... It could be controlled by the user or automated operations.
(I could list thousands of possible ways to apply this....... upload a text document of homework and get it back graded... upload a text document and get it back spell/grammar checked... upload a text document get it back checked for plagiarism... upload some mathematical calculations get back the answers... upload a image of a check and get the money deposited and get the cashed check back)

The web is not simply a collection of pages for you to browse and read. There is a lot of data processing which is done based on file IO...

I know what streams are and I know how to use them.

What you said you are doing is simply parsing an XML file. That is hardly processor intensive. Sending a document to a server to parse the XML and create objects seems like overkill to me. That could very easily be done client side. There is a reason multiple people in this thread have all said they would do this in javascript client side.

But you are stuck in the MS eco system it sounds like, which does not sound fun.

 

[sao123]

I know what streams are and I know how to use them.

What you said you are doing is simply parsing an XML file. That is hardly processor intensive. Sending a document to a server to parse the XML and create objects seems like overkill to me.

That could very easily be done client side. There is a reason multiple people in this thread have all said they would do this in javascript client side.

But you are stuck in the MS eco system it sounds like, which does not sound fun.

Not just parsing the XML file... Dynamically Creating a UI which allows the user to selectively replace parts of the file. There are other reasons for doing such.
MS .Net WebForms is the choice of my employers platform for my development team. Its not in my decision space to decide which technologies are applied to a 14000 person Enterprise.
I understand their decision, as it is easier to create and manage 1 website than to use SCCM to create and deploy winforms software packages to 14000 machines.

For our usual primary purposes (Data Driven, Data Entry Web Portals) Asp.net is the proper tool of choice.
Doing Editable GridView's in plain JS is a nightmare, and JS cannot simply call a SQL Stored Procedure without several steps in between like building a Web Service API
.
C# makes business logic and ADO.net Database Calls to Stored Procedures fairly easy to implement, and make putting the data into the GridView very simple, with a few loops and a few dozen lines of code.
We can stand up a fully interactive fully workflowed application in a few months time.


However...C# is the reason why I was hired... I had previously taught it at a university, and I enjoy it.
Applying C# to ASP.net was very simple, no need to bother with learning JS & CSS as you can do all that in the C#... etc.
Regardless having your IT Staff also do some of your web app development means you give them the easy way to do things... learning 2 languages instead of 6 is better for them.

 

[mxnerd]

IsPostBack

Yes, I can. The system.IO Part is already working... It works, its done. It loads. It saves.

Let's forget IsPostBack problem, object persistency, xml value editing first.

Lets' say after you uploading a small xml file using fileupload web control to the remote 2016 server , saved it there.

Then you load the xml file into webform textarea, modified it in the browser, then how do you save it on your machine - the client? You can't specify where you want to save the file on client's machine in the C# code, can you?

==

I agree with OP that MS' tech does have it's advantage however. It comes with many controls and data grid editing is very easy. But data grid editing for xml will be aweful for xml like what OP has said.

 

[sao123]

Lets' say after you uploading a small xml file using fileupload web control to the remote 2016 server , saved it there.

Then you load the xml file into webform textarea, modified it in the browser, then how do you save it on your machine - the client?

Press Save button on web page. Browser will open the same File-Save as box as when you download any file.

XDocument XMLDoc;

protected void Save_Click(object sender, EventArgs e)
{
    MemoryStream SaveStream;
    XDocument FinalDoc;

    //Temp Code to Fix Object Persistence - reload file
    if (XMLInputFile.HasFile)
    {
        if (XMLInputFile.PostedFile.ContentType == "text/xml")
        {
            XMLDoc = new XDocument();
            using (Stream FS = XMLInputFile.PostedFile.InputStream)
            {
                XMLDoc = XDocument.Load(FS);
            }
        }
        FinalDoc = EditDocValues(XMLDoc);
    }
    //end temp code to fix persistence problem

    //****Actual Save Code begins here****
    //assumes XMLDoc has already been loaded and edited

    String FileName = XMLInputFile.PostedFile.FileName.ToString();

    using (SaveStream = new MemoryStream())
    {
        FinalDoc.Save(SaveStream);
        SaveStream.Position = 0;
        Response.Clear();
        Response.AddHeader("Content-Disposition", String.Format("attachment; filename={0}", FileName ));
        Response.ContentType = "text/xml";

        SaveStream.CopyTo(Response.OutputStream);
        Response.Flush(); //Clear all buffered output
        Response.SuppressContent = true; //Send Http Content to the Client
        HttpContext.Current.ApplicationInstance.CompleteRequest(); //Bypass all events and Complete the Response
    }
}

 

[mxnerd]

Press Save button on web page. Browser will open the same File-Save as box as when you download any file.

XDocument XMLDoc;

protected void Save_Click(object sender, EventArgs e)
{
    MemoryStream SaveStream;
    XDocument FinalDoc;

    //Temp Code to Fix Object Persistence - reload file
    if (XMLInputFile.HasFile)
    {
        if (XMLInputFile.PostedFile.ContentType == "text/xml")
        {
            XMLDoc = new XDocument();
            using (Stream FS = XMLInputFile.PostedFile.InputStream)
            {
                XMLDoc = XDocument.Load(FS);
            }
        }
        FinalDoc = EditDocValues(XMLDoc);
    }
    //end temp code to fix persistence problem

    //****Actual Save Code begins here****
    //assumes XMLDoc has already been loaded and edited

    String FileName = XMLInputFile.PostedFile.FileName.ToString();

    using (SaveStream = new MemoryStream())
    {
        FinalDoc.Save(SaveStream);
        SaveStream.Position = 0;
        Response.Clear();
        Response.AddHeader("Content-Disposition", String.Format("attachment; filename={0}", FileName ));
        Response.ContentType = "text/xml";

        SaveStream.CopyTo(Response.OutputStream);
        Response.Flush(); //Clear all buffered output
        Response.SuppressContent = true; //Send Http Content to the Client
        HttpContext.Current.ApplicationInstance.CompleteRequest(); //Bypass all events and Complete the Response
    }
}

But that's not the System.IO you talked about. That content-disposition is a HTTP protocol. Not a file system read write API function call.

 

[sao123]

But that's not the System.IO you talked about. That content-disposition is a HTTP protocol.

Stream and MemoryStream are both members of System.IO...

There are no streams of any type without System.IO

using System.IO;

Stream Class (System.IO)

Provides a generic view of a sequence of bytes. This is an abstract class.

docs.microsoft.com

MemoryStream Class (System.IO)

Creates a stream whose backing store is memory.

docs.microsoft.com

Are you confusing it with FStream Operations?
Which would be System.IO.FileStream, which I never claimed to use... because that would write the stream to the Servers FileSystem Disk, not the clients.
Granting IIS Worker Thread / IIS Service Accounts permission to write anywhere to the server is a big security risk.

 

[mxnerd]

Stream and MemoryStream are both members of System.IO...

There are no streams of any type without System.IO

using System.IO;

Stream Class (System.IO)

Provides a generic view of a sequence of bytes. This is an abstract class.

docs.microsoft.com

MemoryStream Class (System.IO)

Creates a stream whose backing store is memory.

docs.microsoft.com

Are you confusing it with FStream Operations?
Which would be System.IO.FileStream, which I never claimed to use...

OK.

But you still have no way to specify the file path you want to save on the client's machine, can you?

==

Are you confusing it with FStream Operations?
Which would be System.IO.FileStream, which I never claimed to use... because that would write the stream to the Servers FileSystem Disk, not the clients.
Granting IIS Worker Thread / IIS Service Accounts permission to write anywhere to the server is a big security risk.

The web application needs the ability to do IO Operations on the client using the C# System.IO library

Just saw your update. So why did you say the System.IO need to do IO operations on the client? Click the save button in a webpage to save the file on the local machine is totally different from allowing a browser to access your file system directly.

 

[mxnerd]

Read OP's posts multiple times and think finally understand what OP wants. Because usually web technology is not implemented this way.

The XML file is on local machine, not the server. Yet OP's boss wants OP to write a web application whose code resides on a remote Windows Server running IIS that can access local file system directly if possible, that I don't think you can.

Google it and you probably won't find an answer.

 

[sao123]

OK.

But you still have no way to specify the file path you want to save on the client's machine, can you?

==

No. Unfortunately HTTP 1.1 forbids path data in the header. The user must select the location to save the file to.

Just saw your update. So why did you say the System.IO need to do IO operations on the client? Click the save button in a webpage to save the file on the local machine is totally different from allowing a browser to access your file system directly.

Saving the file on the local machine is the same end result, it just has to go through a HTTPResponse Object, and the user select the path.

Theoretically IF the page code was running in IIS on the local machine System.IO.FileStream could write the file to a desired path, but that is not the intent.
We do not let End Users Run IIS on their machine.

 

[mxnerd]

No. Unfortunately HTTP 1.1 forbids path data in the header. The user must select the location to save the file to.

Saving the file on the local machine is the same end result, it just has to go through a HTTPResponse Object, and the user select the path.

I know that. That's what everyone wants to avoid, isn't it?

Theoretically IF the page code was running in IIS on the local machine System.IO.FileStream could write the file to a desired path, but that is not the intent.
We do not let End Users Run IIS on their machine.

Yep. Running IIS locally solves the problem.

 

[sao123]

Read OP's posts multiple times and think finally understand what OP wants. Because usually web technology is not implemented this way.

The XML file is on local machine, not the server. Yet OP's boss wants OP to write a web application whose code resides on a remote Windows Server running IIS that can ....

Correct up to this point. (AND I am already using the Fileupload Control Referenced in the video Above)
Read a File, Let the User edit the file, Send the file back, let the user save it back to the local machine (either overwrite or write new)... (HTTPResponse protocol does not invalidate the requirements vs the FileStream Method)

And we still have the object persistence problem.

 

[mxnerd]

Wonder how large those XML files are? It makes thing easier if they are on the server.

 

[sao123]

Wonder how large those XML files are?

Sample File I have to work with is 1300 lines and 48Kb. I'm going to say max upper bound would be 10x that... 13000 lines and 500Kb but that would be worst case.

It makes thing easier if they are on the server.

Not sure that is a possibility.
the IIS Server as it has 30+ other internal facing and external facing web applications on it...
Neither End Users, Nor the IIS Worker Service Account have write access to the Server Disk.
Log files arent even allowed to be written to the server, they have to be stored in a database.

 

[mxnerd]

500K is not big at all, what's the reason to keep them locally?

Is this an all Windows environment? Windows Active Directory Group Policy makes user directory setup on the server very easy.

Store the files on the server gets automatic daily backup too.

==

Sorry, just saw your previous reply after posting this.

==

It's hard to do if there are so many limitation both on the server and client side. Better setup a seperate NAS device that supports Active Directory so files can be saved in the NAS and doesn't have to touch the server.

 

[sao123]

500K is not big at all, what's the reason to keep them locally?

Is this an all Windows environment? Windows Active Directory Group Policy makes user directory setup on the server very easy.

Store the files on the server gets automatic daily backup too.

The file contains configuration data for another piece of software...which must be installed and run on the client machine. Thus the XML configuration data has to reside with the application using it.

So... we use a piece of proprietary software that allows Engineers to create a Model of a piece of proposed highway construction.
The software takes the Model and then computes the amount of each type of material needed for the job and uses the cost data in the configuration file for each type of material to give a total cost estimate of the job.

Time Index approximately 4:00.

The entire reason for this project is that the price of all the thousands of materials can fluctuate daily/weekly so the XML Cost Configurations must be frequently updated per project and the XML document placed back into the Bentley Software Folder on the local machine.
For each of the materials in the XML, there may be 5-15 Elements of data, most of which control its behavior within the Modeling Software itself. They are not to be modified. Only 2 Elements are to be modified, which would be the unit cost and the unit...

The purpose was to prevent someone having to modify 13000 lines of Raw XML file every week, and can instead use the web page to quickly find and modify just the Cost Fields for each type of Material. It will be much faster... and much less error prone for someone to accidentally edit a value they are not supposed to.

Every construction project has its own unique configuration file as costs are different by Region, Time of the Year, Supplier, Parameters of the Job... and that file is only useful for a few days to maybe two weeks, then it must be updated again.

That kinda makes keeping the XML file on the server... useless?

 

[mxnerd]

Well, it's kind of mission impossible since all browsers are not allowed to access local file system directly, have to think....

WinForm will make this much easier and that probably will be the only answer.

 

[sao123]

Well, it's kind of mission impossible since all browsers are not allowed to access local file system directly, have to think....

WinForm will make this much easier and that probably will be the only answer.

This is a controlled enterprise environment with a pre-imaged workstation build across all machines.
Assume every local machine Windows 10 Enterprise with Google Chrome.

Chrome will download the file to the local machine file system, using the HTTP Response code above...
We do not need the FileStream Code with a targeted path... The end user will know how (and have the proper windows file system permissions) to use the browser "save as" to save the file into the application directory to update their current configuration file.
Since the user may be running multiple simultaneous jobs, but only have 1 copy of the software, the user actually may need the ability to determine the location where to save the file...

We already use this code in dozens of other applications currently.

This part is *not* an issue.

 

[mxnerd]

OK. Then we can focus on what mus be solved.

 

[mxnerd]

Found probably the best tutorials for ASP.NET.

Well, It's probably the best programming tutorials I have ever watched!

The title says ASP.NET tutorial for beginners, but it's super advanced!

There are 172 videos of them.

https://www.youtube.com/watch?v=3AYoipyqOkQ&list=PL6n9fhu94yhXQS_p1i-HLIftB9Y7Vnxlo

He even has text version of his video!

What is viewstate in asp.net - Part 3

Free C#, .NET and SQL Server Video Tutorials for beginners and intermediate programmers.

csharp-video-tutorials.blogspot.com

Start with video 3. "What is viewstate inasp.net" Just finished viewing this video, can't believe how details this guy explains every aspect of the viewstate, and the stateless of html.

OP please just watch this guy's videos, believed it can solve the object persistency problem OP faced.

Worth every minute of the video.

 

[mxnerd]

Video 5 Session State at 9:24

==

Session storage size concerns

capacity of a session variable

forums.asp.net

 

[mxnerd]

Persistent storage

Persistent storage can help protect critical data from eviction, and reduce the chance of data loss.

web.dev

Storage for the web

There are many different options for storing data in the browser. Which one is best for your needs?

web.dev