The images on this page are not very nice... Should be updated.
Portlets are implemented as Java classes that inherit from the ASPPortletProvider class.
The diagram below shows all methods inherited from the super class that can be overridden in a portlet. Methods are presented according to their execution order, but whether a particular method will be executed during the current request or not, depends on several circumstances.
The very first request of a particular portlet will cause the framework to create a new instance of the corresponding Java class.
The Java Virtual Machine will initiate the whole process by loading the corresponding class file up to the memory and then create an instance of the class by calling the constructor.
After the instance is created the IFS Web Client framework will call the construct()
method to complete the initialization of the instance. But the instance is still
in the Undefined state and no portlet components, like fields, blocks and
tables, are created yet. So the next step will be to call the preDefine()
method to let the portlet make all its definitions.
After it has been done the framework will try to change the status of the
portlet to Defined by calling setDefined() in the super class. This
method will make a call to the freeze() method, which in turn will
call the doFreeze() method in the portlet. After successful return
from the call to setDefine() the portlet will change its state to Defined
and will be put into the Page Pool, but the instance will remain locked until
the request is finished.
The diagram below summarizes the execution order during the very first call:
Subsequent calls
During subsequent requests of a portlet the framework will try to reuse instances from the Page Pool. If a non-locked instance of the corresponding class is found in the Page Pool, it will be locked by the current request and used by the framework.
To perform some necessary initialization after fetching the instance from the
Pool, the activate() method in a super class will be called. This
method in turn will execute the doActivate() method in the current
instance. Then, because of the state of the instance, which is Defined,
the framework will call the init() method.
However if all instances of the corresponding class are currently locked in the Page Pool, which means all instances are currently in use by other threads/requests, the engine has to create a new instance. In order to save system resources and time, the creation is done by cloning one of the existing instances, not by executing the whole process, like the very first time.
To clone an instance the clone() method is called in one of the
existing instances, which is currently locked and used by another thread. The clone()
method will create a new, empty instance by executing the constructor, and then
just copy or clone all own members to the newly created instance. Because the
instance responsible for cloning is currently in use by another thread, it is
extremely important that the instance will not change any of its own members or
the own behavior!
Note: It is not necessary
to write clone( ) and doReset( ) methods in portal pages they are handled
automatically by the IFS Web Client framework.
Diagram below summarizes the execution order during subsequent calls.
Depending on the user choices we can divide the presentation of the portal into two modes: Normal and Customize mode. The execution flow, which will result in a presentation of the portal as a page with a number of portlets presenting their information, is a Normal mode. In opposite, the request, which results in a page that allows configuration of a whole portal or only one, particular portlet, is a Customize mode.
After the initialization, an instance of the portlet class will receive a
call to the run() method. Here the portlet can execute all
necessary business logic and database calls.
After that the framework will prepare the generation of the HTML code, which
will be send to the browser. This task begins with call to the getTitle()
method to obtain a title that will be shown in a portlets title bar. Depending
on the current presentation state of the portlet and the implementation of the
client browser, this method can be called with different input parameters once
or twice. If the client browser is Netscape Navigator, the function will be
called once with the value of the argument, which is one of the predefined
constants: MINIMIZED or MAXIMIZED, depending on the
current presentation state. If the browser is Microsoft Internet Explorer, the
function will actually be executed twice, with both values. Minimalization and
maximalization of portlets in IE is done by DHTML (Dynamic HTML), so the server
must prepare the HTML code for both modes.
After call to getTitle(), the framework will call the canCustomize()
method to decide if the portlet is customizable and if the special customize
icon should be shown on the portlets title bar.
Finally the call to the printContents() method will be performed to
generate the HTML body of the portlet.
After the request has been processed, the framework will call the reset()
method in a super class and then release the instance in the Page Pool for using
of another request/thread. During the execution the instance can eventually
change its state from Defined to Dirty. Modifying different attributes or
enclosed objects, like blocks or fields, can cause this state transition.
However
before the instance can be reused by another request it must make some clean up.
It can be done in the doReset() method, which will be called from
the reset() method during the request finalization process.
The diagram below summarizes the execution order in Normal mode.
The execution order in Customize mode is quite similar to the Normal mode.
First the instance will receive a call to the runCustom() method,
which, like the run() method in Normal mode, works like a
placeholder for all business logic and database calls.
Then the call to getTitle() will be received; this time the
value of the argument is the predefined constant CUSTOM.
And finally, to create the HTML body of the portlet in the configuration
mode, the call to printCustomBody() will be done. Like in case for
Normal mode, the doReset() method will be executed on the request
finalization.
The diagram shows the execution order in the Custom mode.
When the portal engine generates the response in Normal mode, but directly
after the user confirmed his or her customization on the portal or portlet
configuration page by clicking the OK button, the framework will put an
additional method call to the portlet execution order. Directly after the init()
method, but before execution of the run() method, the engine will
call the submitCustomization() method.
Here it is possible to retrieve values of different configuration parameters modified by the user and save them to the user profile.
This function will also guarantee updating of the user profile, stored in the profile cache, to the database.
The diagram shows the modified flow, the case for Microsoft IE.
The table below summarizes all possible execution flows in a portlet.
| Creation | Fetched from pool | Customize mode | Submit customization |
|---|---|---|---|
| <constructor> | [clone()] | ||
| construct() | doActivate() | doActivate() | doActivate() |
| preDefine() | init() | init() | init() |
| doFreeze() | submitCustomization() | ||
| run() | run() | runCustom() | run() |
| getTitle(MAXIMIZED) | getTitle(MAXIMIZED) | getTitle(CUSTOM) | getTitle(MAXIMIZED) |
| getTitle(MINIMIZED) | getTitle(MINIMIZED) | getTitle(MINIMIZED) | |
| canCustomize() | canCustomize() | canCustomize() | |
| printContents() | printContents() | printContents() | |
| doReset() | doReset() | doReset() | doReset() |
A particular portlet will execute in one of following cases:
In other cases the framework will supply the generated portal page with the HTML code fetched from the HTML cache.