01 Request LifeCycle

8/3/2019 01 Request LifeCycle

1/21


2/21

A Web Form in ASP.NET


3/21

After Server-side Processing

EG,

TextBox1 produces:

Typically a page posts back to itself. Clicking

the button causes a form submit event.


4/21

A Note about View State

If you click Button1, Label1 will bechanged to show ("Hello"). When the pagereloads 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 theydiffer from the default values (defined inthe ASPX file).


5/21

ASP.NET Lifecycle Phases

1. Init

2. Load

3. Events4. Render

5. Unload


6/21

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 example

Label1.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.


7/21

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.


8/21

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.


9/21

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 raiseappropriate 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").


10/21

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.


11/21

Lifecycle - 5: Unload

A chance for controls to clean up any

resources they're using like Database

Connections, etc.


12/21

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 thesequence of all major phases in request

processing in a Spring Controller. (And

nothing else!)


13/21

KLUCIS Phases

1. Resource Lookup

2. Init

3. Do Action

1. Execute Event; add DynamicComponents

2. Init&Action for dynamic components

1. Prerender Event

2. Unload and Render


14/21

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").


15/21


16/21

Lifecycle - 3: Do Action

Do the action: In addition to the regularparameters:...?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 theidempotence...).

If action not supported, log warning and ignore (Actions become complicated for rich clients

synchronizing with the server)


17/21

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 listenersand broadcasts the "execute" event...)


18/21

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 theroot CompositeView (or some of its children)

some dynamic components

Dynamic components should also have IDs,

which are generated in a predictable fashion.


19/21

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.


20/21

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

...


21/21

Lifecycle 7: Unload and Render

Release database connections and similarresources

Return ModelAndView from the

SpringController Some small computations and extra

processing of data can be done during the

last moment: in the Velocity templatesduring the Render phase, but this isgenerally not a good practice

Documents

01 Request LifeCycle