portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Milek" <s.mi...@comcast.net>
Subject Jetspeed j2o Desktop Introduction
Date Tue, 09 May 2006 00:43:43 GMT

Over the past few months we've been developing a Web 2.0 desktop mode in
Jetspeed, called the Jetspeed j2o Desktop. Combining server-side Jetspeed
ajax services with client-side services, j2o is a paradigm shift in the way
portlets are viewed and aggregated.

Jetspeed 2.0 is a server-centric application: every request goes back to the
server. The user interface is shackled by HTTP page paradigm.

Jetspeed j2o Desktop is a client-side centric solution. The user interface
is controlled on the client-side. Page aggregation and customization are
among the portal features that have been restructured to allow key
responsibilities to be transferred from server to client. For example, the
server supports an ajax-api for accessing the page model. This enables the
client-side to read the model during page aggregation and to tell the server
when to persist changes to the page definition.

The jetspeed desktop client-side consists of lots of javascript and css.
Dojo toolkit is leveraged heavily. We use dojo for ajax, gui widgets and
general javascript programming. Mainly due to challenges with gui widgets,
we are using bleeding edge dojo (current version in use is the nightly build
from 2006-04-21).

Requesting Jetspeed Desktop

Several enhancements have been made to jetspeed to support shifting certain
responsibilities from the server to the client. These changes start with the
addition of a desktop pipeline. The desktop pipeline is used in place of the
default portal pipeline. In order for a request to select the desktop
pipeline, the webapp context in the url must be immediately followed by
"/desktop". So, for the default webapp context "jetspeed", start j2o with

Response Differences

The content returned for each portal navigation does not contain any portlet
content or PSML. Instead, there are javascript includes (dojo and jetspeed
desktop), page layout html and page layout css.

Rather than calling this a layout-decorator, which it is best likened to,
we're calling it a desktop-theme. Two desktop-themes, "blue" and “tigris”,
are defined at this point. We have equivalent jsp and velocity template
definitions for each desktop-theme (blue.vm, blue.jsp and tigris.vm,
tigris.jsp). Currently, the <skin> element in PSML determines the
desktop-theme for a page.

Client-side Content Aggregation

Jetspeed desktop uses client-side content aggregation. Javascript included
in the desktop-theme starts the content aggregation process. Using the
document URL, PSML is requested via the jetspeed ajax api. Just as with the
regular portal, the jetspeed page manager and profiler do their job and the
appropriate PSML document is returned to the client. This PSML tells the
client-side aggregator which portlets are included on the page Additionally,
the PSML fragments contain the positioning data needed to place each portlet
window in the desktop.

Portlet Content

Window state operations such as minimize, maximize and restore are conducted
on the client-side. The server is notified of changes to the window state of
a portlet, but is otherwise not involved (actually, this notification is not
happening yet, but is intended). Changes in the position of a portlet window
are reported to the server using the ajax api.

Render requests are handled in a way which deviates from what is spelled out
in JSR-168. Only the portlet targeted by the render URL is rendered. This
trade-off is made to exploit client-side aggregation, avoiding the rendering
of all portlets because, now that we can, it is irresistible.  Action
requests are handled normally according to the specification (i.e. all
portlets are rendered). Both action and render requests are handled via
ajax, and therefore replace only the content of each portlet window, not the
entire page. If there is demand from the community, we will adjust the
render request behavior or make it configurable.


Returning to the PSML loading process, menu definitions are retrieved using
the jetspeed ajax api. A menu object model is used to represent parsed menu
definitions. Different widgets can use this object model to present a menu
in their own way (e.g. tab bar, folder/link tree, breadcrumbs). The "blue"
desktop-theme currently includes this tag:

    <div widgetId="jetspeed-menu-pages" dojoType="PortalTabContainer"
style="width: 100%; height: 25px;"></div>

Upon loading of all the menu definitions, a special function,
notifyRetrieveAllMenusFinished, is called to represent this event. A
built-in listener discovers the above widget based on its widgetId. Protocol
is then called on the widget to allow it to populate itself using the
retrieved menu definition. Alternatively, using dojo's event system, any
javascript function can be connected to this event (specifically, the
notifyRetrieveAllMenusFinished function) so that custom menu content can be
constructed without having to use special dojo widgets that implement our
protocol (or use something other than a dojo widget).

Decorator Stylesheets

Just as a desktop-theme is very similar to a layout-decorator, a
window-theme is the j2o version of a portlet-decorator. The window-theme is
designed to be customized by image replacements (e.g. title bar background,
minimize icon, maximize icon) and stylesheet changes. There is a portlet
window template, but it is defined in terms of a dojo template, which is
pretty much html. We plan to make the portlet window template a part of each
window-theme. Currently, there are two window-themes: "tigris" and
"blueocean". The stylesheets for each contain a copy of the respective
portlet-decorator stylesheet along with added styles for the portlet window

Each desktop-theme also has a stylesheet. The blue and tigris desktop-themes
each have a stylesheet that is a copy of the respective layout-decorator
stylesheet (blueocean and tigris). Currently, one style declaration is added
to each desktop-theme stylesheet to override a declaration from

This stylesheet arrangement has helped facilitate the development of j2o,
but certain aspects, like the duplicated stylesheets, definitely need


The current layout scheme is simplistic but we think it is promising. The
number of columns is determined from the PSML fragments and horizontal space
is assigned equally to each column. Portlet windows can then be dragged
intuitively to positions in any of the columns. A portlet window can also be
positioned using absolute coordinates.

We are in the process of designing a better combination of container based
layout (columns) with absolute positioning (without anything that parallels
nested layout definitions).

Portlet Selector

Work is underway on a portlet selector for the jetspeed desktop.

There is more to come, so please stay tuned.

Steve Milek

To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org

View raw message