.NETGURU
ASP.NET form w/lots of controls, only some are visible
Messages   Related Types
This message was discovered on ASPFriends.com 'aspngspeed' list.


Clarke, Kyle E.
I've got a record with a lot of fields to edit. I'd like to edit it on a
single .aspx page, so that state can be maintained entirely by the
postback/viewstate model.

One approach to do this is, if the form could be subdivided into 4 logical
forms, for example, then we have 4 tabs on the form. We also have 4 panels,
each panel holding the controls for the respective tab. A placeholder
control is on the page in the location where any one panel would be
displayed. To make the page easier to edit in VS.NET, we keep the 4 panels
elsewhere on the page, so that they don't all try to occupy the same space.
At runtime, we add the 4 panels to the placeholder control, in the same
order each time so that ViewState is restored correctly. Finally, depending
on the active tab during a given postback, we only make one panel visible,
matching the selected tab. The other panels are not visible.

I know having lots of controls on a page slows down performance a lot. My
question is, does it make a difference if we're talking about a normal
amount of visible controls, plus 3 or 4 times as many invisible,
non-rendered controls? Or are a lot of controls bad, either way?

In other words, how much of a perfomance hit are we looking at to have a
page that has lots of controls (bad) but that only makes visible 1/3, 1/4,
or 1/5 of those controls at any time (but still maintains viewstate for all
the page controls)?

Thanks.

Kyle Clarke
Click here to reveal e-mail address

Reply to this message...
 
    
Fabio Yeon
You will be paying most of the cost of having the controls in the page,
especially if you want the viewstate preserved. Rendering is but a step
during page processing, so there will be some saving from that, but it
won't be too much. The overall cost is just creating and processing the
control tree hierarchy. Now, the amount of data transferred per page
and the render time on the client will be smaller (of course), so there
is still some benefit to your scheme. =20

It also begs the question as to why use viewstate to hold on to all the
data. Is session state not a viable solution for this? There's also
the question of security, since viewstate by default is MAC hashed to
prevent tampering, but is NOT encrypted, so the data, if captured, could
be decoded. There is an option for doing that, of course, but is more
CPU cycles on the server.

Hope this helps.

-----Original Message-----
From: Clarke, Kyle E. [mailto:Click here to reveal e-mail address]=20
Sent: Friday, May 17, 2002 5:22 PM
To: aspngspeed
Subject: [aspngspeed] ASP.NET form w/lots of controls, only some are
visible

I've got a record with a lot of fields to edit. I'd like to edit it on a
single .aspx page, so that state can be maintained entirely by the
postback/viewstate model.

One approach to do this is, if the form could be subdivided into 4
logical forms, for example, then we have 4 tabs on the form. We also
have 4 panels, each panel holding the controls for the respective tab. A
placeholder control is on the page in the location where any one panel
would be displayed. To make the page easier to edit in VS.NET, we keep
the 4 panels elsewhere on the page, so that they don't all try to occupy
the same space. At runtime, we add the 4 panels to the placeholder
control, in the same order each time so that ViewState is restored
correctly. Finally, depending on the active tab during a given postback,
we only make one panel visible, matching the selected tab. The other
panels are not visible.

I know having lots of controls on a page slows down performance a lot.
My question is, does it make a difference if we're talking about a
normal amount of visible controls, plus 3 or 4 times as many invisible,
non-rendered controls? Or are a lot of controls bad, either way?

In other words, how much of a perfomance hit are we looking at to have a
page that has lots of controls (bad) but that only makes visible 1/3,
1/4, or 1/5 of those controls at any time (but still maintains viewstate
for all the page controls)?

Thanks.

Kyle Clarke
Click here to reveal e-mail address

| [aspngspeed] member Click here to reveal e-mail address =3D YOUR ID=20
| http://www.asplists.com/asplists/aspngspeed.asp =3D JOIN/QUIT=20
| http://www.asplists.com/search =3D SEARCH Archives

Reply to this message...
 
    
Clarke, Kyle E.
"Fabio Yeon" <Click here to reveal e-mail address> wrote:

[Original message clipped]

That makes sense. I do want viewstate preserved. OK. So this would cut down
page performance a lot.

[Original message clipped]

I have a lot of issues with Session and try to avoid it whenever possible.
My worst fear with Session is the "clone Window" problem where someone opens
a new browser Window sharing Session state with the original Window.

All the book authors avoid the clone window problem with Session. I find
this a major shortcoming/sweeping a significant issue swept under the rug
for web app development. Here's a description from an unbiased third party:
http://www.csharpfriends.com/Members/Main/Channels/article.aspx?articleID=6
(skip down to "But wasn't that Session thing supposed to help?").

A window opened from another window shares, and therefore can overwrite the
same location in Session. Or, if you store things via a unique (you thought)
key in session, and you store that key in ViewState, and you CTRL-N (in IE)
to open a new window, the key is cloned in ViewState in the new window and
you have the same problem.

Other folks on my team who've worked a lot with earlier versions of IIS/ASP
have war wounds from Session, though I believe from that point of view it's
greatly improved in IIS5/ASP.NET.

So, I'm looking for alternatives to Session, or good algorithm(s) to defeat
the various flavors of the clone Window problem.

Server-side redirects have several of their own problems. Nonetheless, I use
them in some places where, without the clone Window problem, I'd use
session.

ASP.NET eliminates another approach to solving this -- posting from one page
to another via the form action. Within ASP.NET, posts must be postbacks. So,
the strategy within ASP.NET I was thinking of is to have a multi-tab form
always "postback" -- hence, all controls are on a single form, rendered
visible/invisble as needed. But, it sounds like this is going to be a very
SLOW form.

Thanks....

Reply to this message...
 
 




ExamGuru IT Solutions - .Net Guru is owned and operated by ExamGuru, Inc., the man behind .Net Guru. If you're in the market for bespoke software or software consultancy, why not get him and his highly trained team to help? - www.examguru.net/ITCertification
Ad


Need Dot Net Interview Questions?
Ask ExamGuru, Inc. for advice and help on Passing .Net Interviews
.Net Projects
Best-of-breed application framework for .NET projects, developed by ExamGuru, Inc. and ExamGuru IT
Free .net Help
Commission ExamGuru, Inc. and his team for your next bespoke software project
FogBUGZ
The only bug tracking system carefully crafted with one goal in mind: helping teams create great software.
Awesome Tools
If you don't know about these, you're missing out... IT Certification Questions
IT Interview Questions
Free Oracle 10g Training
MCSE Boortcamp
Cisco Study Guides
Cheap Study Guides
Exact Questions
Dot Net Interview Questions
Oracle OCP
Cheap Travel
Designer Perfumes - Wholesale Prices
Free Programming Tutorials
 
ExamGuru IT Solutions - .Net Guru is owned and operated by ExamGuru, Inc., the man behind .Net Guru. If you're in the market for bespoke software or software consultancy, why not get him and his highly trained team to help? - www.examguru.net/ITCertification
 Copyright © ExamGuru, Inc. 2001-2006
Contact Us - Terms of Use - Privacy Policy - www.dot-net-guru.com - www.examguru.net - www.oraclesource.net - www.itinterviews.net - www.examguru.net/ITCertification