Forum Moderators: open
I have third parties delivering applications to me using the .NET platform and boy oh boy, is this an exciting challenge! Here is a prime example...
There are six (06) steps involved in a certain process. Once the user hits Step 1, that VIEWSTATE grows a bit and it all depends on the amount of data that needs to be stored on the client side for that first step of the six (06) steps involved.
Now the user hits Step 2, wham, the VIEWSTATE is appended with all the data that needs to be stored on the client side for the second step.
This process continues until the user has reached Step 6 at which time the VIEWSTATE has been appended six (06) times. The example I reviewed yesterday had over 4,000 characters of encrypted VIEWSTATE code.
Man am I happy I have an experienced .NET programmer on board. He's taught me quite a bit in the last 180 days and we've been able to trim those VIEWSTATE's down to a few hundred characters and even less depending on the steps involved. Since I'm a firm believer in "no more than three (03) clicks", we're well under the 300 character mark.
Damn .NET Postbacks! There are Pros and Cons to this entire process. Those Postbacks are great to stop spiders. Heck, they'll even confuse the average human visitor if they looked at the html. Those Postbacks are also responsible for adding to your "Bag of Bricks" during a checkout process.
What type of performance issues does one run into when they are toting around a 100k+ VIEWSTATE session while browsing a .NET site?
Can I assume that I'm the only one seeing these types of issues? And that "all of you" are not using .NET Postbacks and your VIEWSTATE's are less than 300 characters?
Or is it that I'm one of a handful of people brave enough to work on a Windows platform? :)
For private sites though I do use postbacks, but either use some compression to compress the viewstate saved in the page or have a custom postback code to store the postback information in a db row, and only leave the row reference number in the page. This is all so that the end users do not suffer speed or performance issues that would crop up with large viewstate transfers.
Some proxies choke on large viewstates also, I have learned to work around those issues in the different versions of dot.net.
I deal with a lot of dial up/low bandwidth users so download/upload speeds mater a lot.
Am I correct in assuming that Postbacks are a Client Side method of storing information? Could I also assume that it is a "all or nothing" proposition? You're either going to do it Client Side or Server Side, one or the other. Or, do you do a combination of both? Please, forgive my basic questions, I am not a programmer. ;)
Let's talk performance. Does "page weight" not concern a developer when working on Intranet Applications? I mean, you are still dealing with users and I would think performance is of the utmost importance, yes?
So, how do you efficiently deal with dropping a load of lead (VIEWSTATE) on the visitor during their browsing experience whether it's on an Intranet, Extranet, or the Internet?
As for intranet application on 10/100 base t network the viewstate size (effect on page weight) doesn't matter because it has more then enough bandwidth to move it along with ease. And most intranet (local network) application are there only for a limited purpose and never get to the point where they can be that finally tuned. There always the next big project, that is already behind schedule. And no one ever gets a chance to come back to it to clean it up once it is pushed out, except for minor bug fixes and such.
As I said in my first post I usually compress the viewstate down as low as possible to make it work, or I do not send the whole viewstate but only a reference where I can load it from the database. Thus avoids the slow down in the user experience, but storing page state in a db require maintenance to remove old records and such and procedures to handle when those deleted records are asked for so a proper error can be thrown.
Best bet when designing pages/controls really really make sure what needs to be put and saved in viewstate and what doesn't belong in there. I cache the data displayed in read-only displays, and make sure they are not put into viewstate. Most Microsoft controls put all settings in the viewstate which bloats it fast. I had to write my own wrappers around the ones I use to reduce the viewstate bloat for items that will always be set via code and will not need to be round tripped. By doing this first and with compression of the viewstate as it is saved in the page I have been able to reduce the page size (weight) to a more reasonable size. There are exceptions for website designed for mobile/dial-up users where any bandwidth savings is usually looked favorably on. I usually have been able to reduce the viewstate under a few hundred characters, for most reasonable data entry pages.
Does it have to sit right after the <body> element?
How do I get to where that code is being generated? Right now we have an issue where the VIEWSTATE is prefixed with an underscore (id="_VIEWSTATE) and this is not valid HTML, I need to fix it. You can't imagine how much of challenge that has presented. :)
It would be great if I can position that block of code at the bottom of the source. But, I have a feeling you are going to tell me that it has to be before any of the functions. If that is the case, why can't it go into the <head> or an external file?
Can a .NET site run without the VIEWSTATE function?
Are these all valid questions? Remember, I'm not a Programmer but I know enough to talk about it a little and get myself in too deep. ;)
All the viewstate is is a serialized dump of control state, which is uses a hidden form field to round trip the data. So any place you can put a hidden field and get it round tripped back as part of the post back data will work. But moving it will be the tricky part of it, that will require some coding to do it nicely. There are other older forum threads on this I just can not find them presently.
As for the invalid html, I think you are wrong the <input type="Hidden" name="__VIEWSTATE" id="__VIEWSTATE" value=""> is valid. I know the naming convention may not be liked by all.
A asp.net site can run without viewstate. But almost every control but the most simple control will use viewstate, unless specifically designed not to use it which most are not.
