Hi Steve, Is j2o available in the version control? Thanks.
On 5/14/06, David Le Strat <[EMAIL PROTECTED]> wrote:
Thanks for the post Steve. I checked it out and this is very nice. Regards, David Le Strat ________________________hDavid Le Strat Blogging @ http://dlsthoughts.blogspot.com ----- Original Message ---- From: Steve Milek <[EMAIL PROTECTED]> To: jetspeed-dev <[email protected]> Sent: Monday, May 8, 2006 8:43:43 PM Subject: Jetspeed j2o Desktop Introduction Introduction 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 http://localhost:8080/jetspeed/desktop. 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. Menus 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 widget. 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 portal-standard.css. This stylesheet arrangement has helped facilitate the development of j2o, but certain aspects, like the duplicated stylesheets, definitely need improvement. Layouts 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Regards, Cuong Hoang
