Scott on Writing

Feedback

# RE: On a Related Note - Large Web Forms 7/22/2004 12:42 PM nospamplease75@yahoo.com (Haacked)

In terms of switching between design view and html, I hear Whidbey is a lot faster at that. But in VS.NET, I haven't found anything that speeds that up short of never opening design view.

# re: On a Related Note - Large Web Forms 7/22/2004 12:58 PM Scott Mitchell

But without switching to design view, you have to manually enter the Web control references in the code-behind class.

This is no fun when you have 300 of 'em.

# re: On a Related Note - Large Web Forms 7/22/2004 2:05 PM scott

{shrugh} use a text editor. I have my default HTML editor in Visual Studio set to EditPlus. I double click on the .aspx/ascx and it pops up in EditPlus. Sure I have to enter in the references in the code behind by hand but if Visual Studio isn't going to WORK... I guess I'll have to.

# re: On a Related Note - Large Web Forms 7/22/2004 4:41 PM Michael Teper

You could politely ask your client to stop smoking crack and think for a second about the experience their users will have with the page. Beyond that, is there any possibility in splitting up the page into more manageable user controls?

# re: On a Related Note - Large Web Forms 7/22/2004 4:59 PM Darren Neimke

Hi Scott, I feel your pain. I recently had to port a VB6 windows application to a WebApp where there were humungous lists and dozens (or hundreds) of controls per page.

Even though pages were coming in at > 400K I still couldn't convince the client to re-architect how things were done.

Some of the techniques I used to make life more enjoyable were:

- Doing heaps of processing in the client to try and avoid as many postbacks as possible

- Split pages into functional UserControls.

Breaking the functions down and packaging them as UserControls is probable why I never noticed the sliggishness when switching views.

With V2 (Whidbey) I might be inclined to use the RemotePostbacks to handle these kinds of situations.

# re: On a Related Note - Large Web Forms 7/22/2004 6:35 PM Ron Green

Find a new client? ;-)

# re: On a Related Note - Large Web Forms 7/22/2004 11:17 PM Petr Šnobelt

You can write your oun dropdownlist, which fill their items by JS (which will be cached).
And optionaly they can be filled on first acces to items (like tree on MSDN)...

# RE: On a Related Note - Large Web Forms 7/23/2004 2:30 AM Luke Harris

How about splitting the UI into different user controls. That way you can design and test each functional group of user controls, then pull them all together to produce the end result. It would also make it easier to customise screen layouts, perhaps not displaying all of the UI for some users. The various ASP.NET Portal projects use dynamic loading of user controls for this.

It's also easier to change when the customer comes back and says 'sorry we were wrong, can you split the form over a dozen pages please?'

Luke

# re: On a Related Note - Large Web Forms 7/23/2004 7:20 AM George Hicks

I've had a couple of projects that had such a beast. Overriding the Page to store the viewstate somewhere else(Session, Cache, DB, File) is a must both for performance and to avoid hitting viewstate corruption issues(this was a very frustrating issue to figure out). No tips for the VS performance except setting the HTML Designer Web Form option to Start In HTML View.

In one case, I abandoned the visual designer approach altogether for a meta data driven dynamic form building approach. This was a lot of work up front and required a deep understanding of how webforms work, but it paid off by keeping me sane.

In another case, the project required a form that had 16+ variations depending on data conditions. The same data could be used in different ways, but the sequence and inclusion of fields varied from condition to condition which altered how the end result was calculated. The field inclusion rules prevented most of the visual encapsulation options(server controls, user controls, panels) so I had to use dynamic controls again for different portions. This project was to replace a series of complex spreadsheets(with a high human error risk). Here again, I could not ignore the inner workings of web forms.

# re: On a Related Note - Large Web Forms 7/23/2004 7:48 AM Scott Mitchell

Petr, I am actually considering writing my own custom DDL for this, loading via JavaScript. This would be particularly time-saving since about five of the biggest DDLs on the page have exactly the same 1,000+ rows.

# re: On a Related Note - Large Web Forms 7/27/2004 6:05 AM dhananjay singh

Hi Scott,
I will suggest u can refrector functionality in logical group and put those functionality on diffrent .aspx pages.
Then in main .aspx page just put frames for these different pages.
U can put one hidden frame for storing globle hidden data for u r bussiness logic.Which u can manipulate from javascript as well as from code behind.
And this approch help in u r round trip problem also, only single frame is going to get refresh after post back event(mostly....).
And other thing u know the best ;)
If u need some explination on this please fell free to contact me on dhananjay123@hotmail.com

# re: On a Related Note - Large Web Forms 7/29/2004 7:56 AM Mark

I also am currently working on a project converting an enormous financial spreadsheet over to ASP.Net with very large pages (the largest is 12,000+ lines of code) and 700k. I keep getting viewstate corruption on a Windows 2000 machine running web matrix. This computer is very unstable, so it is probably just one of those things I'll have to live with. Everything works great using web matrix on XP and on the web server. Any thoughts?

# re: On a Related Note - Large Web Forms 8/3/2004 12:00 PM Mark

For my large forms, I like to name each control type in a sequence number. For example, on one page I have probably 200 checkmarks. I named them CheckBox1, CheckBox2 etc. Then, if I need to apply some change to all of them, I actually write the code in Excel normally just using basic Excel functions and the auto sequencing of numbers Excel provides. Sometimes I have to resort to using VBA to try and prevent tedious code changes. It's worked well for me so far b/c I know Excel very well.

# re: On a Related Note - Large Web Forms 8/23/2004 7:49 PM Josh Thuya

I have been working with "huge" web forms as well (200+ controls per page). And having the same ViewState corruption error.

Is there anyway to rewrite the page so that viewstate is stored in DB?

I can't avoid using viewstate because I dont want to refill the values whenever the form is posted back.

Any suggestion?

# re: On a Related Note - Large Web Forms 8/23/2004 7:55 PM Scott Mitchell

Josh, you might want to read this article of mine:

Understanding ASP.NET ViewState
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/viewstate.asp

Among other things it talks about storing view state to an alternate backing store, as well as the role of view state.

hth

# re: On a Related Note - Large Web Forms 9/30/2004 1:19 PM balu s

My little brain cannot understand the
User Interface Process Application block but

in its documentation it says...

I quote from MS docs

"One of the goals of the User Interface Process Application Block is to provide the ability for users to suspend a session, and then be able to restart it from the same point with any information previously entered having been saved. ..."

May be you could write an article on this.....

I earn my living with your articles (mostly)...

Thanks....

( Will deriving from existing controls work and then have a property called ExistingValue which would take Chicago|LA and then selected those two in the drop down list or something.

Title:
Name:
Url:
Enter the code you see:
Comments
Remember Me?