There has not yet been a jetspeed release which includes j2o desktop, but the svn trunk contains everything. Instructions here:
http://portals.apache.org/jetspeed-2/source-code.html Steve -----Original Message----- From: Cuong Viet Hoang [mailto:[EMAIL PROTECTED] Sent: Sunday, June 11, 2006 8:24 PM To: Jetspeed Developers List; David Le Strat Subject: Re: Jetspeed j2o Desktop Introduction 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
