AJAX support for content
Whereas the layout and renderer contribute to AJAX behavior at the markup
level, JBoss portal's support for object-level confi guration can be leveraged
to provide AJAX support at the page level. The object property inherits a confi
gured behavior from its parent. Currently, two features are offered for
AJAX-driven content:
-
Drag and drop: Facilitates easy movement of portlets to various locations on
screen using the mouse.
-
Screen Refresh: Allows sub-components of pages or individual portlets to
refresh themselves without refreshing the entire page.
Drag-and-Drop
As the name suggests, this feature is triggered by a user action, and allows a
portlet to detach itself from a specifi c location on the page and move to a
different location on the page. This allows for the customization of the user
interface to a form that is most convenient to the user. The dynamic view
behavior comes from a combination of DHTML and asynchronous server-side
communication.
Due to the nature of the behavior, drag-and-drop capability is available and
effective only in dashboard pages where there are multiple portlets and the
page layout can be personalized. The feature is allowed by default on the
dashboard, but can be turned off by setting the value in the confi guration fi
le to false.
The following is a snippet of the default object confi guration fi le
(jboss-portal. sar/conf/data/default-object.xml), which illustrates the
enabling of the feature. Please note that this can also be confi gured using
the administration console user interface of the JBoss server.
<deployment>
<if-exists>keep</if-exists>
<context>
<context-name>dashboard</context-name>
<properties>
...
<!-- Set the dnd property -->
<property>
<name>theme.dyna.dnd_enabled</name>
<value>true</value>
</property>
...
</properties>
</context>
</deployment>
<name>theme.dyna.dnd_enabled</name> value enables or disables the
drag-anddrop behavior.
Partial content refresh
One of the most expensive processes in a portal is the refresh of portlets when
the page is generated. For every user action on a page, the portal calls all of
the portlet methods in a serial, but non-specifi c order, which involves a
signifi cant amount of time and server-side processing. Partial content refresh
support mitigates these issues to a large extent with an effective use of
client-server asynchronous communication. When the state of a single portlet
changes, a partial content refresh facilitates the update and refresh of only
that portlet, instead of for all of the portlets on the page. This prevents the
regeneration of the whole page and the initialization of all of the portlets on
the page.
The following image illustrates the partial content refresh fl ow:
The partial refresh capability is compatible with the JSR-168 portlet API, which
allows for programmatic update of portlet states during runtime.
Partial refreshes can be enabled through portal object confi guration or through
confi guration at the default server level.
Portal object configuration
To implement partial page refreshes successfully, the properties of the portal
objects need to be updated to include the property, theme.dyna.partial_refresh_
enabled, which takes the values true or false. The deployment descriptor
appears as follows:
<deployment>
<if-exists>keep</if-exists>
<context>
<context-name>dashboard</context-name>
<properties>
...
<!-- Set the dnd property -->
<property>
<name>theme.dyna. partial_refresh_enabled</name>
<value>true</value>
</property>
...
</properties>
</context>
</deployment>
For changing the behavior during runtime, the property editor of the management
portal can be used to set the values at the default server level. Once set, all
of the pages in the portal automatically inherit the property. The default
portal confi guration is shown in the following screenshot:
Portlet configuration
Although the default portal confi guration enables partial refreshing for all
portlets, it is also important to understand when a portlet would actually use
a partial refresh. Having this knowledge helps us to control the behavior at
the portlet level.
The server, by default, enables partial refresh for action and render links.
However, there are the following exceptions for which the whole page is
refreshed:
-
Forms with GET requests. Using a GET request is discouraged by the portal
specifi cation. Hence, this should not be of signifi cant concern.
-
Form uploads.
-
A window in a MAXIMIZED state. Partial page refreshes will not function when
the window is entering or exiting a MAXIMIZED windows state.
There are, however, a few scenarios where we don't want to use a partial refresh
at all. In such cases, partial refreshes can be disabled by using the following
confi guration in the portlet descriptor fi le, jboss-portlet.xml.
<portlet>
<portlet-name>TestPortletBlockPartialRef</portlet-name>
<ajax>
<partial-refresh>false</partial-refresh>
</ajax>
</portlet>
Setting the <partial-refresh> value to false prevents partial refreshes of
portlets when they are invoked.
Constraints in implementing partial refresh
Although partial refresh is a powerful option, it has certain constraints on
both the client and server sides.
Inconsistent session attributes
When a page is partially refreshed, the state of the page and its relationship
to the portlets on the page become inconsistent. The direct impact of this is
the session variables. If a partially-refreshed variable updates a session
variable, a different portlet using this same variable will continue to use old
data and might not be able to update to the latest session data.
In such cases, selective enabling of partial refreshes for portlets should
address the problem.
Non-AJAX interaction
The AJAX implementation for partial refreshes is triggered by DOM events
generated by the user in the browser. However, the user doesn't trigger these
events. The portal JavaScript has no way of knowing the request, and hence
might refresh the whole page.
A good example of this is the direct programmatic submission of forms, instead
of relying on browser events for submission.
For issues like these, care should be taken when coding the portlets, and using
constructs that do not generate DOM events should be avoided.
Also read
What is a Portlet? Explain its capabilities.
Explain Portal architecture.
What is PortletSession interface?
What is PortletContext interface?
Why portals?...................
|
