You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by Cuong Viet Hoang <cl...@gmail.com> on 2006/06/12 04:24:11 UTC
Re: Jetspeed j2o Desktop Introduction
Hi Steve,
Is j2o available in the version control? Thanks.
On 5/14/06, David Le Strat <dl...@yahoo.com> 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 <s....@comcast.net>
> To: jetspeed-dev <je...@portals.apache.org>
> 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: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>
>
--
Regards,
Cuong Hoang
RE: Jetspeed j2o Desktop Introduction
Posted by Steve Milek <s....@comcast.net>.
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:climbingrose@gmail.com]
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 <dl...@yahoo.com> 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 <s....@comcast.net>
> To: jetspeed-dev <je...@portals.apache.org>
> 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: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
>
>
--
Regards,
Cuong Hoang
---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org