Typically a page posts back to itself. Clickingthe button causes a form submit event.

A Note about View State

•If you click Button1, Label1 will bechanged to show ("Hello"). When the pagereloads Label1 will still say "Hello", eventhough it's default value is "A Label!".

•ASP.NET inserts a hidden field into theform (_VIEWSTATE) which holds thecurrent state of all controls where theydiffer from the default values (defined inthe ASPX file).

ASP.NET Lifecycle Phases

1.Init

2.Load

3.Events

4.Render

5.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 achance to update its state. For exampleLabel1.Text = "Hello". (View State data is keyedby Control ID).

•Anything in the View State that didn't match aknown control ID is placed in an "Unmatched"list.

•Turn on view state tracking. Any changes tocontrols will now be recorded in the View State.

Lifecycle-

1: Init

•When the form was submitted some controls (forexample TextBox1) will submit their values as a{ID, value} pairs. We call this the Post Data.

•As before, we match Post Data against controlby ID, giving each control a chance to processthe data. Some controls may decide to trigger anaction based on this, so they get added to a"Pending Actions" list.

•Finally any unmatched Post Data also getsadded to an "Unmatched"

list.

Lifecycle-

2: Load

•This is a chance for controls to access thedatabase, etc.[Not all such controls needto be visible.]Some dynamically createdcontrols may be added to the tree at thisstage.

Lifecycle-

3: Events

•We make a second pass of any data saved inour "Unmatched" list. This is for the benefit ofdynamically created controls.

•We find the control that caused the post backevent and see if it has any events it needs toraise-

(typically things like Button1 "On Click").

Lifecycle-

4: Render

•View state tracking is turned off & ViewState serialised into the hidden_VIEWSTATE field.

•Controls generate HTML based on theircurrent state.

Lifecycle-

5: Unload

•A chance for controls to clean up anyresources they're using like DatabaseConnections, etc.

Now about KLUCIS requestlifecycle

Definition: A Spring Controller is acomponent/module, which is responsiblefor the lifecycle of a single HTTP request.I.e. it is appropriate to code thesequence of all major phases in requestprocessing in a Spring Controller. (Andnothing else!)

KLUCIS Phases

1.Resource Lookup

2.Init

3.Do Action

4.Execute Event; add DynamicComponents

5.Init&Action for dynamic components

6.Prerender Event

7.Unload and Render

Lifecycle 1: Resource Lookup

•Lookup the servletPath in RDF data. I.e.extract from the HTTP request the desiredimageName and find in N3 description suchresource r that [r klucis:hasImageName"imageName"].

•May need special processing, if imageNamedoes not exist, or is ambiguous, or some errorhappens during the processing-

ideally wouldhave special "PageNotFound" and"InternalServerError" resources (i.e. a "404image" and an "500 image").

Lifecycle-

2: Init

•Create a component for r and all the staticresources referenced by it (all creation is doneby the rdf:type of these resources-

lookup inComponent Factory)

•Load the request state to ComponentManagerand 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 regularparameters:

...?compId1=state1&compId2=state2&...

there can be a single pair of special actionparameters:

..._ac=someId&_aa=someAction

•If component with the id=someId understandsthe action, it is executed (should care about theidempotence...).

•If action not supported, log warning and ignore

•(Actions become complicated for rich clientssynchronizing with the server)

Lifecycle 4: Execute event

•Interact with the database or with RDFresource set, or do other things whichcomponents want to do

•Events are executed on all components,which are EventListeners; these can bedone in any order. (ComponentManagerstores a table of all registered listenersand broadcasts the "execute" event...)

Lifecycle 4: Add Dynamiccomponents

•Upon certain conditions during the "execute"event (e.g. if the states of the static componentsbecome appropriate, or if the DB/RDF query hascertain response-

etc.), create and add to theroot 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 havetheir state among the HTTP requestparameters, initialize them accordingly.

•If there is any remaining action ondynamic components, execute theseactions.

Lifecycle 6: Prerender Event

•All the SVG components calculate andcommunicate their width, height, offsets,etc. to prepare for the drawing.

•Facetted browse components compute theavailable future states from the existingstates of their neighbors and populatethemselves with labels

•...

Lifecycle 7: Unload and Render

•Release database connections and similarresources

•Return ModelAndView from theSpringController

•Some small computations and extraprocessing of data can be done during thelast moment: in the Velocity templatesduring the Render phase, but this isgenerally not a good practice