BusinessRx Community

These blog entries are written by industry experts and leaders. We consider this content to be a good read for any software developer or web technologist.

July 2004 - Posts

• On a Related Note - Large Web Forms

  Earlier today I posted about large view state issues.  Another issue that faces me with this current project I'm working on (which goes hand-in-hand with the large view state problems), are large Web Forms.  By this I mean the client wants a single Web page with a gaggle of form fields.  By “large” I'm talking about, in some cases, over 300 Web controls on a single page.  (For the record, this is the client's specs, not my design!) Has anyone worked on projects before where Web Forms of this size were common?  There's a number of issues I'm having that are a bit annoying, and was wondering if there are any tips/hints in helping circumvent these problems.  Some of the annoyances of large Web Forms include: Visual Studio .NET drags.  Switching from HTML view to Design view means it's time to go downstairs and get a soda. When visiting the page for the first time after any changes have been made to the HTML portion, it takes a good four or five seconds for the ASP.NET engine to autogenerate the class that derives from the code-behind class.  This won't be an issue in deployment, but is annoying when you need to make a small change to the HTML in a page. View state can get very large, as I alluded to earlier.  This is especially the case when using DropDownLists. The code for populating these Web controls with database data and, conversely, reading the data from the controls when saving, can be cumbersome.  Usually if I have a series of related controls I'll give them some sort of similar ID value, and then use a loop and FindControl together to snap through a dozen or so related Web controls in three lines of code as compared to 12. Any tips or helpful suggestions appreciated.  Thanks! Posted Thursday, July 22, 2004 8:22 AM from Scott on Writing | 0 Comments

• Largest. ViewState. Ever.

  The ASP.NET DataGrid Web control is notorious for its hefty view state size, but the DropDownList control can hold its own weight as well, especially when it contains a lot of items.  For example, a page containing nothing but a DropDownList populated with ~100 items from a database will yield around 10 KB in view state.  While 10 KB might not seem like much, remember that view state is a two-way penalty - it is sent down with the page's HTML and sent back during postback, thereby increasing both the download and postback time for the end user. I just finished a page that, I think, will hold record as having the largest view state.  Ever.  Working on a site for a client and he needs a page that has over a dozen DropDownList controls, and each DropDownList has, believe it or not, upwards of 1,000 items.  End view state?  Over 800,000 bytes.  In total, the page was over 2.5 MB in size.  What does this mean for an average dialup user?  Well, they'll have to wait nearly six minutes to download the page, and eight minutes to postback (two minutes to upload the 800 KB of view state, six minutes to download the 2.5 MB again). Of course, I cut the view state down to a few KB by turning off view state for the page.  It wasn't needed since I wasn't programmatically changing the state of the controls on the page, nor was I using the SelectedIndexChanged event of the DropDownList.  But still, the page weighs in at 1.7 MB, which is still prohibitively large (even though all users are really on an intranet). Posted Thursday, July 22, 2004 4:37 AM from Scott on Writing | 0 Comments

• Firefox nonbug that caused me some grief today

  I ran into a rather unfortunate issue today with a server control that I thought would probably be good to talk about. The issue is created by non-bugs that come together to make a bug. Firefox persists the values of form fields when the user refreshes the page. Firefox does not persist any script objects applied to the document or the window Complex server controls will commonly use script objects for the lifetime of the page, and use hidden inputs to round trip values from server to client to server. So this is the result of these 3 items... A user with firefox hits your page with your control on it the first time... Your initialization script runs, and all script objects and hidden inputs are in the initialized state. The user plays with the page a bit, and your control changes its state, changing object properties and hidden input values. The user hits refresh in their browser. Firefox nullifies all script objects, but retains the values of the hidden inputs. Your control's initialization runs again, but now the script objects are created with hidden input state that is not the original. Now, as you can imagine, this has a very high possibility of completely borking your control. Now, before I get flames, let me restate that I don't consider this a bug in Firefox. It's just a behavior that I hadn't planned for. However, ultimately, it has a way of changing my methods for roundtripping values between client and server. For now, my best solution is to include any "initial" values in the RegisterArrayDeclaration call for the control, while previously i would normally only put them in the hidden input. Share this post: Email it! | bookmark it! | digg it! | reddit! Posted Wednesday, July 14, 2004 4:18 PM from Andy Smith's Blog | 0 Comments Filed under: asp.net controls