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

sao123

Lifer
May 27, 2002
12,648
201
106
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.
 

Ken g6

Programming Moderator, Elite Member
Moderator
Dec 11, 1999
16,250
3,845
75
Short answer: HTML is stateless, but JavaScript is not. JavaScript has lots of places to save state, starting with cookies. Modern browsers have local storage.

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...
JavaScript can make POSTs without changing the HTML page. This started with XMLHttpRequest, but there are a few other methods now too.

It's a little hard to make out some of the things you're talking about, like XDocument, because Microsoft puts wrappers around some web standards. But it sounds like "WebApp Document Editors" may be a component in a framework to make a progressive web app (PWA).

Handling connection attempts when there's no connection to the server is something "service workers" are supposed to handle, though I've never used one. And I'm not sure if that's what you meant, anyway.
 

sao123

Lifer
May 27, 2002
12,648
201
106
Short answer: HTML is stateless, but JavaScript is not. JavaScript has lots of places to save state, starting with cookies. Modern browsers have local storage.


JavaScript can make POSTs without changing the HTML page. This started with XMLHttpRequest, but there are a few other methods now too.

It's a little hard to make out some of the things you're talking about, like XDocument, because Microsoft puts wrappers around some web standards. But it sounds like "WebApp Document Editors" may be a component in a framework to make a progressive web app (PWA).

Handling connection attempts when there's no connection to the server is something "service workers" are supposed to handle, though I've never used one. And I'm not sure if that's what you meant, anyway.

Keep in mind this is ASP.net...
Every page is made of Markup (Serverside HTML controls) and Page behind c# Code that defines the functionality (Page Load, Event Handlers, etc)

XDocument is a C# class/object in the Page Behind Code which allows for easy traversal of an XML documents elements attributes and values. It is essentially the binary form of an XML document.
This is the document (Dataset) I want the user to be able to edit.

Asp.net uses the Session State on the server to save data, but it times out after X minutes, so that is not reliable. It has to be somewhere on the client...

So to simplify...
Editors like Microsoft Word, Google Docs, Notepad++, etc all run locally.
When you open a file you have the entire document in main memory, even though only 1 page of the document is rendered on the screen.

In a disconnected web application (stateless html), there is no main memory to store the entire document, only the portion rendered on the screen persists between page load and save/submit.
Where can I safely store the non-rendered portion of the document on the client, so that when I press the save button, the entire document is intact, not only the part shown in the browser on the screen?

You mentioned a cookie, but can a cookie store an entire document in a place which cannot be tampered by the user or other processes? My limited understanding of cookies is they are not secure.
 

mxnerd

Diamond Member
Jul 6, 2007
6,799
1,101
126
Download open source online editors and take a look of their code?


And maybe it also has anything to do with web proxy caching server (Apache Traffic Server or alike?) around the world? Just guessing.

Also launch Chrome built-in Developers tools see what could going on in the background. Like Applicaion Storage, Cache, etc.

*No longer a programmer, but still interested in the topic generally*

==

Searched for you. 😁


==

Or maybe it's IIS server side setting?

 
Last edited:

purbeast0

No Lifer
Sep 13, 2001
52,859
5,732
126
You can store it in a cookie or local storage. With knowledge, the user can edit/view/delete it.

The only way to store it somewhere that the user has no way to do anything with it is sending it to a webserver. You don't have to then store it to this proprietary ASP session state that loses it after some time. Store it to a database and it will be there until you want to remove it.

Just because on the client all you "see" is one page of the document does not mean that is all that is there in memory. It just depends what the API returns. It could very easily return the whole document if you want it to. It's completely up to the developer as to what they want to do. Some API's have paging where you only have the data for the page you are on, then you can have things for instance, like virtual tables, where all the data may be there but it's only displaying (rendering) whats in the current view.

It appears you have your terminology mixed up. You say "web application (stateless html)" which is just wrong. The web application is everything - front end and backend. It's not just the stateless HTML as you mention. All modern websites/apps are not "just" HTML. They are javascript or some other language dynamically generating this HTML with a lot going on behind the scenes in the other language, looking for changes, to modify the HTML.

I'm also not sure what you mean by "disconnected" web application. You got the document from somewhere, presumably a backend server, which would mean that it is not disconnected.
 
  • Like
Reactions: mxnerd

Ken g6

Programming Moderator, Elite Member
Moderator
Dec 11, 1999
16,250
3,845
75
After re-reading your requirements, if it was me I'd do the entire thing in JavaScript as a single-page application. JavaScript can read even local files, parse XML, certainly display controls, and even allow you to save the result.

But it sounds like you put in a lot of work on the ASP side. I suppose you could serialize your XDocument and push it back and forth. (Ugly and bandwidth-intensive, though.) Could you cache the serialized XDocument somewhere on the server?
 

purbeast0

No Lifer
Sep 13, 2001
52,859
5,732
126
Yeah I don't know if you are bound to ASP because this is for work, but generally speaking I'd steer clear of Microsoft's stuff for web applications if you can. I've just never been a fan of it and with how mature javascript is now with all the frameworks and npm, there is a lot out there.
 

mxnerd

Diamond Member
Jul 6, 2007
6,799
1,101
126
What OP meant disconnected web probably is that once the webpages/datasets have been displayed locally, user then can disconnect the network and will not cause an error.

==

Found another two very popular javascript based web editors
https://CodeMirror.net demo https://codemirror.net/1/htmltest.html

and

https://ace.c9.io demo https://ace.c9.io/build/kitchen-sink.html

both support xml format

OP might want to download the code from Github and take a look.

==

But I think OP of course does not want to let end users edit the xml file directly, he really need to fetch the needed xml data (not the whole xml document), display them in the form, let user edit the fields and save it back to the server, probably like what @Ken g6 has suggested.
 
Last edited:

purbeast0

No Lifer
Sep 13, 2001
52,859
5,732
126
What OP meant disconnected web probably is that once the webpages/datasets have been displayed locally, user then can disconnect the network and will not cause an error.
If that is the case, and you can still view the whole document even if it's not rendered all at once, then clearly you have the whole document in memory somewhere and then can save it to local storage.

Also I've used CodeMirror extensively in the past and it's a beast. It can be very tricky to get it to do what you want it to do.
 
  • Like
Reactions: mxnerd

sao123

Lifer
May 27, 2002
12,648
201
106
I guess I wasnt clear or left out a detail... there is no database. I am trying to do all Front End Processing in IIS. Code behind and back end are not the same entity.
I want the web page to mimic the same behavior a standalone application would be able to do if it was installed on the client machine.
The user browses to a file stored on his local machine, is meant to do all the editing and then store the file again on his local machine. No back end storage whatsoever.

I think what I may end up doing is storing the entire document within a hidden div on the page itself or in a cookie.
 

purbeast0

No Lifer
Sep 13, 2001
52,859
5,732
126
If the file is stored on their local machine, why don't you just store it on their local machine?

I'm even more confused by your last post lol.

I'm also not sure why you are trying to reinvent the wheel in making a document editor :p
 
  • Like
Reactions: mxnerd

Cogman

Lifer
Sep 19, 2000
10,277
125
106
I guess I wasnt clear or left out a detail... there is no database. I am trying to do all Front End Processing in IIS. Code behind and back end are not the same entity.
I want the web page to mimic the same behavior a standalone application would be able to do if it was installed on the client machine.
The user browses to a file stored on his local machine, is meant to do all the editing and then store the file again on his local machine. No back end storage whatsoever.

I think what I may end up doing is storing the entire document within a hidden div on the page itself or in a cookie.

Sounds like you need a better understanding of how IIS + ASP.NET and your browser work. Saying "I am trying to do all Front End Processing in IIS" is nonsensical. IIS is a backend server. The only thing on the frontend is Html, css and javascript (and web assembly...).

If you are writing C#, that code all runs on your server. ASP.NET is just a fancy way to wire together the server and client communication (it works very hard to hide that interaction).

I'd echo Ken's advice. The right way to do this is a single page app. You are going to end up with something awful trying to shoehorn this kind of interactivity with ASP.net.
 
  • Like
Reactions: Ken g6 and mxnerd

mxnerd

Diamond Member
Jul 6, 2007
6,799
1,101
126
OP is completely confused about the concept of client/server.

If OP wants to process the document locally, just use C# and WinForms.

No need to make things complex by using ASP.Net (back end) and IIS.

Even if OP finished his project and the XML file he mentioned is stored locally using ASP.net, he need to install IIS or a web server on every machine he wants to run his app.
 
Last edited:

sao123

Lifer
May 27, 2002
12,648
201
106
Sounds like you need a better understanding of how IIS + ASP.NET and your browser work. Saying "I am trying to do all Front End Processing in IIS" is nonsensical. IIS is a backend server. The only thing on the frontend is Html, css and javascript (and web assembly...).

If you are writing C#, that code all runs on your server. ASP.NET is just a fancy way to wire together the server and client communication (it works very hard to hide that interaction).

I'd echo Ken's advice. The right way to do this is a single page app. You are going to end up with something awful trying to shoehorn this kind of interactivity with ASP.net.

Asp.net is considered a Rich Client Side framework... It is still all front end.
ASp.net webforms does not work the same that MVVM Javascript webpages work.

in every ASP.net Webforms page, there is the .ASPX markup part (and the designer.cs file) and the .CS code behind part which contains all the page logic and functionality.

The code runs on the IIS server... thats not the "back end", that is the "Code Behind". It is still part of the page...
This defines what happens on page load, what happens when I press this button, what happens when my cursor enters or leaves a control or a value is selected in a control. C# defines all the AJAX work through a series of async postback events.

The "back end" is business logic and database operations, this would be ADO.net not ASP.net. Which is what I am saying, this project will never have a database or cloud services component.
Regardless this is all immaterial to the problem...


You must understand the page lifecycle of asp.net

I think the concept you are missing is this... IN a standard C# .NET console or Windows Application Classes and objects persist until they pass out of scope and are garbage collected. All the data fields of the object remain until the entire object is out of scope.

In the ASP.net webforms, all objects pass out of scope and are garbage collected at the end of each HTTP Postback.
An object created in the page load, does not persist between postbacks...what happens in page load will never be available in button press unless you store that value in a html control or cookie or cache or session.

Code:
Class Page
{
    protected int x;

    void protected page_load()
    {
        if (!IsPostBack())
        {
            x = new int();
            x = 3;
        }
    }

    void protected button1_click()
    {
        textbox.text = x;
        //WILL NOT PRODUCE 3 because the page object is garbage collected between page load and button press.
    }

}


This is why ALL page load functions include the code
if (!IsPostBack()) {}
Every postback including button press calls the page load function.


I believe the correct answer might be the viewstate instead of the session state.









OP is completely confused about the concept of client/server.

If OP wants to process the document locally, just use C# and WinForms.

No need to make things complex by using ASP.Net (back end) and IIS.

Even if OP finished his project and the XML file he mentioned is stored locally using ASP.net, he need to install IIS or a web server on every machine he wants to run his app.

i'm not confused about a client and a server, I am trying to make a server behave as a client. The same way that Word 365 Online mimics the behavior of Word.exe 2016 installed locally.
We are not allowed to use winforms, because we are not permitted to install software on client machines... it has to be done in a browser so there is 1 copy on a master IIS, rather than each change or improvement has to be redeployed to 14000 machines.
 

mxnerd

Diamond Member
Jul 6, 2007
6,799
1,101
126
The full name of ASP is Active Server Pages, it's server side, so it's back end. No browser can execute .net code unless it's run inside of Internet Explorer IIRC.

ASP.NET use .NET framework to generate javascript/html code on the fly that browsers (front end) can consume, explicitly or implicitly.

All browsers can run is javascript/html code either stream from the server or load locally.

Code behind means exactly that, it's run behind the web page, not in the web page. The code is run on .NET framework (a lot of dll files) that either comes with WIndows or you download it from MS website and install on the machine.

If you visit any aspx webpage and you open the developer tools that comes with Chrome/Firefox or even IE and view the web page source code, all you see is html + javascript, not aspx code.

==

If you are not allowed to use WinForms, then do whatever you need to do.

==

.NET has been moving to .NET Core direction. Where the code can be run on WIindows/Linux/(and Mac?) But you need to install .NET core framework on all machines that act as a server.
 
Last edited:
  • Like
Reactions: purbeast0

mxnerd

Diamond Member
Jul 6, 2007
6,799
1,101
126
ASP(X) model

Untitled.jpg

Browser on other platforms can still visit aspx web pages without .NET framework installed on their machines. That's because the browsers on Linux/Mac still only run the html/javascript code generated by ASP.NET on the server that stream to them.

Doing ASP.NET development on your own machine does not mean it's front end.
 
Last edited:

sao123

Lifer
May 27, 2002
12,648
201
106
The full name of ASP is Active Server Pages, it's server side, so it's back end. No browser can execute .net code unless it's run inside of Internet Explorer IIRC.

ASP.NET use .NET framework to generate javascript/html code on the fly that browsers (front end) can consume, explicitly or implicitly.

All browsers can run is javascript/html code either stream from the server or load locally.

Code behind means exactly that, it's run behind the web page, not in the web page. The code is run on .NET framework (a lot of dll files) that either comes with WIndows or you download it from MS website and install on the machine.

If you visit any aspx webpage and you open the developer tools that comes with Chrome/Firefox or even IE and view the web page source code, all you see is html + javascript, not aspx code.

==

If you are not allowed to use WinForms, then do whatever you need to do.

==

.NET has been moving to .NET Core direction. Where the code can be run on WIindows/Linux/(and Mac?) But you need to install .NET core framework on all machines that act as a server.


Were just going to have to agree to disagree on this.
In our N-Tiered Service Model the terms "client"/"server" and "frontend"/"backend" are not synonymous.
The front end tier includes everything in the presentation layer which includes the IIS Servers.
For this particular application I cannot cross that red line.


I believe this best describes our definition of Front End/Back End.

I think it just depends on how you look at it. I agree that because ASP.net is
server-side it should therefore technically be considered a "back-end" tier.

However when compared, for example, to a VB6 application the part that
creates the forms and presents the data to the user (creates the UI) is
considered the "client". For this reason most people think of the ASP.net tier
as being the client or "front-end" because it is responsible for generating
the part the user interacts with.
 

Attachments

  • nTier.png
    nTier.png
    195.7 KB · Views: 6
Last edited:

sao123

Lifer
May 27, 2002
12,648
201
106
ASP(X) model

View attachment 21026

Browser on other platforms can still visit aspx web pages without .NET framework installed on their machines. That's because the browsers on Linux/Mac still only run the html/javascript code generated by ASP.NET on the server that stream to them.

Doing ASP.NET development on your own machine does not mean it's front end.

???
The code is NOT ON MY MACHINE. It is deployed to a shared IIS Server.
Where do you get this?

The only things on my machine are:
1 The input file.
2 The output file.
3 The browser doing the operation



why are we still discussing front end back end instead of solving the actual problem?
 

mxnerd

Diamond Member
Jul 6, 2007
6,799
1,101
126
It has nothing to do with 2 tier on n-tier. The concept is the same.

???
The code is NOT ON MY MACHINE. It is deployed to a shared IIS Server.
Where do you get this?

The only things on my machine are:
1 The input file.
2 The output file.
3 The browser doing the operation

why are we still discussing front end back end instead of solving the actual problem?



The concept is the same for ASPX

The only things on my machine are:
1 The input file.
2 The output file.
3 The browser doing the operation

Did you mention this at all in your previous posts? Then why did you say you are mimicing? You don't have a remote or local server, how do you mimic?

The code is NOT ON MY MACHINE. It is deployed to a shared IIS Server.
So you want to write your code to mimic existing code that's already deployed on the shared IIS server? Did you mention this at all?

Sorry, I'm done. You can't even describe what you have, what you don't have. What mus be done on server side or client side.

Maybe someone else can help.

Join https://forums.asp.net and ask questions there.
 

sao123

Lifer
May 27, 2002
12,648
201
106
It has nothing to do with 2 tier on n-tier. The concept is the same.





The concept is the same for ASPX



Did you mention this at all in your previous posts? Then why did you say you are mimicing? You don't have a remote or local server, how do you mimic?


So you want to write your code to mimic existing code that's already deployed on the shared IIS server? Did you mention this at all?

Sorry, I'm done. You can't even describe what you have, what you don't have. What mus be done on server side or client side.

Maybe someone else can help.

Join https://forums.asp.net and ask questions there.

The problem is you havent understood the question, you went way overboard on some tangent about whether it is a client or server operation which is not essential to the question.

You are WAY over complicating this. Its very simple data editor which performs file operations within a browser.
Read this and forget all the client server front end back end crap.

i have everything completed up to step 10. Step 10 has created an issue which is questioned below the steps.


1 The following is to be accomplished using a Asp.net 4.62 WebForms Visual Studio Project as a Single Page Application.
2 The code will be deployed to a remote IIS Server within the company network which is firewalled off from external users.
3 There are no databases or other servers or other resources available to use for this project. There are no security or restrictions who may use this system, so no connections to active directory are needed.
The combination of the browser and the hosted website must completely accomplish the following.

4 The user will interact with the code using a standard web browser. Example: Chrome
5 The user will perform a file>open command (Within the Website Form Controls, Not using the browser menu) to allow the application to read an xml file from the local machine. This will be done with a Stream Object.
6 The website will use the XDocument, XNode, XElement, XAttribute, and XComment c# objects to parse the data from the Stream Object.
7 The website will parse the XML XDocument and dynamically create label controls and load identification data (names) into them within the page.
8 The website will parse the XML XDocument and dynamically create textbox controls and load data (values) into them within the page
9 The application will not display the entire XML document or structure, only specific tag names and values which are intended to be user modifiable.
10 The user will then be able to modify the data in the text boxes using the keyboard for data entry.
11 The user will then be able to do a File->Save to overwrite the input file or File->Save As to create a complete new one copy. The new or updated file will have the modified values inputted by the user. These controls are part of the web page application, not the browsers save buttons.

The question is thus:
From Page Load TO any Save Operation the XDocument objects do not persist between postbacks as they go out of scope and are garbage collected.
The file I read in is no longer in the server memory when it is time to do the save.

When I need to save the full document to a blank empty file, I no longer have the entire file contents to merge the edited data back into. I don't want to have to ask the user to do a file->open again as part of the save process to recreate the XDocument objects.
How do I best persist the binary XDocument data between the 2 postbacks so I do not have to re-read the file from the local filesystem every time the users presses the save button.

is the Answer... A div within the page? The Browser Cache? The Client View State? The Server Session State? A Cookie?

Because the user may start editing data, and then walk away. Or may make many changes to the data taking several hours... the Server Session Object is NOT desirable as it has a timeout value afterwhich if no recent postbacks have occurred, the server session is discarded.
Because the user may accidentally open multiple broswer sessions to the same file, out of synchronization may occur, this needs to be prevented.
 
Last edited:

purbeast0

No Lifer
Sep 13, 2001
52,859
5,732
126
I hate to break it to you, but the IIS server IS the backend server.

Just because you are running it on your machine doesn't mean it is front end.

Your browser is the front end. The IIS server is the backend.

There are many technologies where the HTML is generated on the backend and sent to the front end. It sounds like this technology is one that does just that.

I don't how else to make it anymore simple of an explanation at this point.

There is no "agreeing to disagree" you are just wrong.

This is also a perfect example of why I would never use this proprietary Microsoft technology for web applications.
 

sao123

Lifer
May 27, 2002
12,648
201
106
I hate to break it to you, but the IIS server IS the backend server.

Just because you are running it on your machine doesn't mean it is front end.

Your browser is the front end. The IIS server is the backend.

There are many technologies where the HTML is generated on the backend and sent to the front end. It sounds like this technology is one that does just that.

I don't how else to make it anymore simple of an explanation at this point.

There is no "agreeing to disagree" you are just wrong.

This is also a perfect example of why I would never use this proprietary Microsoft technology for web applications.

This is the last time I am going to say this for people who cannot read or understand...
I AM NOT RUNNING IIS ON THE LOCAL MACHINE. IT IS RUN ON A FULL ON WEB SERVER WINDOWS SERVER 2016 ENTERPRISE

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.
The browser can and does already do this work.

This discussion of terminology has nothing to do with the functionality problem being addressed.
C# Object persistence is an issue regardless of where the code resides.
 

Ken g6

Programming Moderator, Elite Member
Moderator
Dec 11, 1999
16,250
3,845
75
i have everything completed up to step 10. Step 10 has created an issue which is questioned below the steps.
Like I said earlier, the best way to do this task would be to re-do it entirely in JavaScript. However, you have sunk costs, in that you've written most of this task in c#.

So, assuming you don't want to re-do everything in JavaScript, you need to find a way to cache these XML files more permanently. You can do this on the server or the client, though there will always be something on the client.

Client-side caching can be done with JavaScript's local storage or session storage. You can't guarantee storing more than about 5MB of string data this way. You could also try a hidden textarea or something. Chrome is starting to purge its cache of sites that haven't been looked at recently, but I think it might keep data in things like textareas. Any way you do client-side caching it also means sending the whole file back-and-forth with the server frequently.

The last alternative is server-side caching. Take the XML file (or serialized object) and save it somewhere on the server with a random string identifier. A date/time stamp would help make that unique. The identifier can be stored on the client in a cookie. The problem with this is an extension of the same problem you're already having: You're using space on the server; how long should the file stay there before it's deleted?

Because the user may accidentally open multiple broswer sessions to the same file, out of synchronization may occur, this needs to be prevented.
Finally, what does this mean? If the user opens a second browser session and loads the same local XML file, should data from the first editing session be imported? Or should they be independent editing sessions that just happen to be based on the same file?
 
  • Like
Reactions: Jaskalas

purbeast0

No Lifer
Sep 13, 2001
52,859
5,732
126
This is the last time I am going to say this for people who cannot read or understand...
I AM NOT RUNNING IIS ON THE LOCAL MACHINE. IT IS RUN ON A FULL ON WEB SERVER WINDOWS SERVER 2016 ENTERPRISE

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.
The browser can and does already do this work.

This discussion of terminology has nothing to do with the functionality problem being addressed.
C# Object persistence is an issue regardless of where the code resides.
This is the last time I am going to say this for people who cannot read or understand...
I AM NOT RUNNING IIS ON THE LOCAL MACHINE. IT IS RUN ON A FULL ON WEB SERVER WINDOWS SERVER 2016 ENTERPRISE

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.
The browser can and does already do this work.

This discussion of terminology has nothing to do with the functionality problem being addressed.
C# Object persistence is an issue regardless of where the code resides.

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

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

Then you say this...

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

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

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

At this point I have no clue what you are talking about and don't think you clearly grasp the whole front end (client) and backend (server) concept. Maybe you do and you just aren't explaining stuff as you want to, but you're requirements have contradictions from a conceptual level.

Without knowing exactly what you need, I am 100% positive that using good old HTML and javascript would make this so much simpler.
 
  • Like
Reactions: mxnerd

mxnerd

Diamond Member
Jul 6, 2007
6,799
1,101
126
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.

I also don't understand this
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.
The browser can and does already do this work.

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