Page LifeCycle in ASP.NET

Page LifeCycle in ASP.NET

A Web Form in ASP.NET <form id="form1" runat="server"> <asp:Label ID="Label1" runat="server" text="A Label!"/> <asp:Label ID="TextBox1" runat="server" text="A TextBox!"/> <asp:Button ID="Button1" runat="server" onClick="Label1.text='Hello'"/> </form>

After Server-side Processing EG, TextBox1 produces: <input type="Text" id="TextBox1" name="TextBox1" value="A TextBox!"/> Typically a page posts back to itself. Clicking the button causes a form submit event.

A Note about View State • If you click Button1, Label1 will be changed to show ("Hello"). When the page reloads Label1 will still say "Hello", even though it's default value is "A Label!". • ASP.NET inserts a hidden field into the form (_VIEWSTATE) which holds the current state of all controls where they differ from the default values (defined in the ASPX file).

ASP.NET Lifecycle Phases • Init • Load • Events • Render • Unload

Lifecycle - 1: Init • Build up a tree of controls from the ASPX file. (All controls have their ID set at this stage) • Process the View State, giving each control a chance to update its state. For example Label1.Text = "Hello". (View State data is keyed by Control ID). • Anything in the View State that didn't match a known control ID is placed in an "Unmatched" list. • Turn on view state tracking. Any changes to controls will now be recorded in the View State.

Lifecycle - 1: Init • When the form was submitted some controls (for example TextBox1) will submit their values as a {ID, value} pairs. We call this the Post Data. • As before, we match Post Data against control by ID, giving each control a chance to process the data. Some controls may decide to trigger an action based on this, so they get added to a "Pending Actions" list. • Finally any unmatched Post Data also gets added to an "Unmatched"list.

Lifecycle - 2: Load • This is a chance for controls to access the database, etc. [Not all such controls need to be visible.] Some dynamically created controls may be added to the tree at this stage.

Lifecycle - 3: Events • We make a second pass of any data saved in our "Unmatched" list. This is for the benefit of dynamically created controls. • We process the "Pending Actions" list and raise appropriate events (things like TextBox1 "On Changed"). • We find the control that caused the post back event and see if it has any events it needs to raise - (typically things like Button1 "On Click").

Lifecycle - 4: Render • View state tracking is turned off & View State serialised into the hidden _VIEWSTATE field. • Controls generate HTML based on their current state.

Lifecycle - 5: Unload • A chance for controls to clean up any resources they're using like Database Connections, etc.

Now about KLUCIS request lifecycle Definition: A Spring Controller is a component/module, which is responsible for the lifecycle of a single HTTP request. I.e. it is appropriate to code the sequence of all major phases in request processing in a Spring Controller. (And nothing else!)

KLUCIS Phases • Resource Lookup • Init • Do Action • Execute Event; add Dynamic Components • Init&Action for dynamic components • Prerender Event • Unload and Render

Lifecycle 1: Resource Lookup • Lookup the servletPath in RDF data. I.e. extract from the HTTP request the desired imageName and find in N3 description such resource r that [r klucis:hasImageName "imageName"]. • May need special processing, if imageName does not exist, or is ambiguous, or some error happens during the processing - ideally would have special "PageNotFound" and "InternalServerError" resources (i.e. a "404 image" and an "500 image").

Lifecycle - 2: Init • Create a component for r and all the static resources referenced by it (all creation is done by the rdf:type of these resources - lookup in Component Factory) • Load the request state to ComponentManager and initialize the components accordingly (e.g. some image subcomponent has been rotated; some form field has some bookmarked value, etc.)

Lifecycle - 3: Do Action • Do the action: In addition to the regular parameters: ...?compId1=state1&compId2=state2&...there can be a single pair of special action parameters:..._ac=someId&_aa=someAction • If component with the id=someId understands the action, it is executed (should care about the idempotence...). • If action not supported, log warning and ignore • (Actions become complicated for rich clients synchronizing with the server)

Lifecycle 4: Execute event • Interact with the database or with RDF resource set, or do other things which components want to do • Events are executed on all components, which are EventListeners; these can be done in any order. (ComponentManager stores a table of all registered listeners and broadcasts the "execute" event...)

Lifecycle 4: Add Dynamic components • Upon certain conditions during the "execute" event (e.g. if the states of the static components become appropriate, or if the DB/RDF query has certain response - etc.), create and add to the root CompositeView (or some of its children) some dynamic components • Dynamic components should also have IDs, which are generated in a predictable fashion.

Lifecycle 5: Dynamic init&action • If the newly created components have their state among the HTTP request parameters, initialize them accordingly. • If there is any remaining action on dynamic components, execute these actions.

Lifecycle 6: Prerender Event • All the SVG components calculate and communicate their width, height, offsets, etc. to prepare for the drawing. • Facetted browse components compute the available future states from the existing states of their neighbors and populate themselves with labels • ...

Lifecycle 7: Unload and Render • Release database connections and similar resources • Return ModelAndView from the SpringController • Some small computations and extra processing of data can be done during the last moment: in the Velocity templates during the Render phase, but this is generally not a good practice

Page LifeCycle in ASP.NET