portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raphaƫl Luta <raphael.l...@networks.groupvu.com>
Subject Re: PSML related object model
Date Mon, 18 Jun 2001 17:02:09 GMT
Chuck Johnson wrote:

> Raphael,
> As I study the Jetspeed architecture and source code, one of the things that
> troubles me is the object model surrounding the PSML and Portlets.  As I can
> tell, the basic flow is as follows:
> PSML XML File --> Profiler Service --> Profile --> PSMLDocument -->
> Portlets -->  PortletSet
> I'm not sure that I have this totally understood yet, but it seems to be an
> area that has suffered from some evolutionary demise.

3 quick notes on this:
- first, there's definitely some "evolutionary" weight in the process and it can
   definitely be streamlined
- second, one of the major step for streamlining this is to remove the Castor
   generated API and use a hand-craft OM API that is persisted using Castor
   mapping files (ie do to PSML exactly what has been done for the Registry)
- third, the process you describe is not exactly linear as stated, the relevant
   relations are rather:

   request parameters ---------------+---------------> Profile (config locator)


  Profile ----------------+-------------------------> PSMLDocument (config)

   PSMLDocument include a Portlets object (the config document itself)
   and provide manipulation methods on the document. These 2 objects will
   be merged together when the PSML API will be moved to an interface based
   object model API.

   Once you have a PSMLDocument, you can completely manipulate the pane
   description for a given portal page, you only need to get a PortletSet
   if you want to render a page and actually have portlets processing the

> I think I have seen comments from David along these same lines, as well as
> some comments in the code calling out areas for improvement.  I was
> wondering if there is any effort underway to streamline this part of the
> object model.

The steps are defined, but right now, as far as I know, nobody is tackling
them... feel free to step in.

> Is this related to the effort described in the TODO as "Substitute the
> layout engine with a new stream-based one"?

Somewhat related but not completely, the layout process needs to be reimplmented

to work better with the new Portlet API which is completely stream-driven.
Right now, the buffered model of Turbine is expensive to use in Jetspeed because
we have to handle a lot more of small buffers generated by the different control,
controller and portlet. Switching to a pure stream model will probably increase
the global performance of the engine.

Raphael Luta - raphael.luta@networks.groupvu.com
Vivendi Universal Networks - Paris

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

View raw message