placing runat="server" in body tag causes discrepancies with loadi

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Placing runat="server" in the body tag causes discrepancies with our loading.
We require this capability to programmatically modify the body tag and add /
remove controls depending on user permissions. HOWEVER, when this tag is
added NO control which has its child items (most notably dropdownlists)
declared in the page_load function will load viewstate. The value of the
control is pulled neither in the first ProcessPostData nor the
ProcessPostData SecondTry. Creation of the child items must be moved to the
Init event to properly pull the data.

My questions are several:

1. Why are there two attempts at loading the post data in the first place?
Why aren't developers given access right away to both the init and page_load
functions seeing as how there is lots of processing before the page_load? It
seems as though this is just a waste and removes a lot of power from the
developer's hands. Why is the default function for a Page class the
page_load when that's halfway through the loading process?

2. Why would a page function normally and load viewstate for a control,
EVEN if its child items are declared in page_load, without the runat="server"
in the body but not with the tag declared?

3. Is there any way I can see the code for the inherent functions such as
what causes the trace for "ProcessPostData," etc? I'd like to know how the
system determines which events to fire based on post data. As we are
deriving from the Page class and customizing it heavily I will eventually
need to determine how to override some of this inherent behavior.
 
Inline

--
-Philip Rieck
http://philiprieck.com/blog/
1. Why are there two attempts at loading the post data in the first
place?
Why aren't developers given access right away to both the init and
page_load
functions seeing as how there is lots of processing before the page_load?
It
seems as though this is just a waste and removes a lot of power from the
developer's hands. Why is the default function for a Page class the
page_load when that's halfway through the loading process?
Click to expand...

You have access right from the Page's constructor. page_load is a
convenient place because viewstate, post data, etc has all been loaded
already - so controls seem "stateful" at this point. However, you can hook
whatever part of the page you need before this. The full ASP.Net pipeline
(more than just Page, but Page as well) has a lot of hooks. Don't limit
yourself to the default ones created by the designer.

2. Why would a page function normally and load viewstate for a control,
EVEN if its child items are declared in page_load, without the
runat="server"
in the body but not with the tag declared?
Click to expand...

Loading viewstate is a tricky beast for controls that are dynamically
created. Basically, when a control is added to the form's control's
collection, it will be told to load it's viewstate, which is done by ID,
based on a form post, etc.. To cut to the chase, you're problems are
twofold -

1) you're dynamically creating controls that are not in the form's controls
collection (they will be in a child control), so there can be many possible
problems there (id mismatch, viewstate not available, not loaded
automatically) This can work with discipline.

2) your <body> tag is outside the page's form. ASP.NET assumes that all
server-side controls are inside the single page form.


3. Is there any way I can see the code for the inherent functions such as
what causes the trace for "ProcessPostData," etc? I'd like to know how
the
system determines which events to fire based on post data. As we are
deriving from the Page class and customizing it heavily I will eventually
need to determine how to override some of this inherent behavior.
Click to expand...

Look at Lutz Roeder's .net reflector program.
http://www.aisto.com/roeder/dotnet/

And Frit'z Onion's "Essential ASP.NET" book.
 
Back
Top