The NWS Tutorial

Life cycle of a NWS page and its components

WARNING: This tutorial is being written! Do not hesitate to report any errors or suggestions.

Quick access:
The various stages of the life cycle

NWS is qualified of "framework": this is not just a library of Web application development, but this really a development system of web applications imposing a strong frame of programming. Among the different items imposed by this framework, we can mention the life cycle of a web page. This life cycle imposes the invocation of particular methods at any strong moments of the treatment cycle of the web page. The chart below attempts to synthesize this life cycle.

The various stages of the life cycle

To better understand the situation, we will now resume one by one the different points of the life cycle of a NWS page.

The life cycle of a NWS page begins with the construction of the web page object (derived from the class corelib.services.web.server.WebPage). It is not advisable to use the manufacturer: at this stage, the object is not yet linked to the definition file of the web page (extension .wp).

In second stage, the NWS framework seeks to manage the included files. Don't remember that a NWS web page is necessarily defined through an XML file. The same goes for the different files included (through the syntax <include file="partOfPage.wp" />). The inclusion is in reality taked by merging the differents DOM (Document Object Model), to finally have a single DOM representing the complete NWS webpage. The fusion is obtained by a simply cloning of the XML tags, identically, in the main page.

At this point the NWS framework seeks, for each node of the associated DOM with a Web component, to instantiate these various components. Don't remember that the XML namespace of each tagconsidered is in reality associated with a Java package. Do not forget that it is also possible to make a name tag coinciding exactly with a class name fully qualified (ex: <corelib.services.web.components.Button />). The NWS framework also seeks to inject the tags' attributes of the WEB components in the attributes of your web components request on the basis of the javaBeans model.

Some attributes of your Web page class can be linked to both NWS annotations corelib.services.web.annotations.Session and corelib.services.web.annotations.Session. If so, the NWS framework will bind these requests with the associated datas (stored respectively in session or in the application). If the datas don't exist at this time, the framework will seek to instantiate them (through the engine of java reflection: it is necessary that the classes of these datas expose a constructor with a zero parameter).

For all the web components that implements the interface corelib.services.web.server.DataRepeater (the repeaters of web components), we attempt to clone the web components they contain. As a standard, the repeaters of components are linked to datas in session or stored in the application. For all the duplicated components, the identifiers of web components (property id) are modified to ensure the uniqueness of each of them (the repetition index is associated with them).

The initialization step is then unleashed: it is divided into two parts. You will be notified of this event through an event approach that spread over the two steps mentioned below (items 7 and 8).

The method component_init is invoked on each of the web components. Warning: At this stage you don't yet have access to the linked datas (through the Data Binding), nor to the submitted datas through a form (except, of course, through the object request - javax.servlet.http.HttpServletRequest).

The method page_init is invoked on your webpage. Warning: At this stage you don't yet have access to the linked datas (through the data Binding), nor to the submitted datas through a form (except, of course, through the object request - javax.servlet.http.HttpServletRequest).

The DataBinding (step 1/3) begins in initializing each Web component with the model objects datas related to them.

All the submitted datas through a form (in case of submission in POST) are recovered in the request object and stored in the web components associated.

The DataBinding (step 2/3) is pursued by copying the datas (possibly modified by the previous step) of the objects components to the javaBeans requests of the model. It will be possible at the event management to work, with a purely object approch, on the objects of the model (and not on those of the considered - MVC architecture).

The events that indicate the end of the datas loading of the page began to be invoked: it continues during the stages 13 and 14. Note that, contrary to the event of initialization, you have access, for now, to all the datas put into play by the Web page.

The method component_load is invoked on each of the web components.

The method page_load is then invoked on the page. Conventionally, it is in this way that you encode the registration of the listeners on the web components of the page (the event model proposed by the framework).

The management of events on the Web components of your page continues. The calls will be launched in blocks respecting the five levels of priorities proposed by the framework (WebComponentEventLevel.FIRST, BEFORE, DEFAULT, AFTER and LAST).

The DataBinding (Step 3/3) is ending. The events managers have probably changed the model datas. We must therefore move, one more time, the state of model's beans to the web components, in order to prepare the stage of generating of the HTML rendering.

The generation of the HTML rendering begins now: the DOM XML may have been altered by you and the web components reflecting the new state resulting of the actions of the user, we can now manage the all to produce the HTML page to return to the client. This generation step of the HTML page continues until the point 25.

The method page_preRender is invoked on the web page considered. While some final adjustments are necessary, it is still possible to react.

Then, the method page_render is invoked. It has a responsibility to make cascading the request of generating HTML flow on the root tag of the DOM and its associated Web component (usually it is the component <web:Html>).

The method component_preRender is invoked on a component to inform him that it is about to be asked to take instructs its visual rendering.

The method component_renderBegin must generate the HTML code associated with the opening tag of the Web component considered.

The method component_renderChildren must generate the HTML code associated with the contents of the Web subfeatures considered. It is not necessarily need to recode this method. Its implementation in the classroom VisualComponent will suffice in most cases. In the case of the component contains any Web subfeatures, the default implementation returns to the method component_preRender, component_renderBegin, component_renderChildren, component_renderEnd and component_postRender and that for all the sub-components.

The method component_renderEnd must generate the HTML code associated with the closing tag of the Web component considered.

The method component_postRender is invoked to indicate to the Web component in question, that its work of HTML flow generation is finished.

The method page_postRender is invoked to indicate that the generation of the HTML flow associated with the webpage is finished.

The object of Web page is released by the framework. It is now possible that the GC (Garbage Collector) uses this object (and those who are associated with it): the method finalize will finally be used.

CAUTION : NWS is proposed to you in BETA version to allow evaluation of this framework. Infini Software is released from any responsibility for the use of framework NWS. In addition, Infini Software can in no way be liable for the use of information contained in these tutorials.