life cycle of asp.net

Page LifeCycle in ASP.NET:

Page LifeCycle in ASP.NET

A Web Form 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:

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:

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:

ASP.NET Lifecycle Phases Init Load Events Render Unload

Lifecycle - 1: Init:

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:

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:

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:

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:

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:

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

Now about KLUCIS request lifecycle:

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:

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 :

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:

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:

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:

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:

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:

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:

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:

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