cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Neeme Praks" <>
Subject RE: Cocoon and Jetspeed
Date Thu, 01 Jun 2000 14:32:52 GMT

> -----Original Message-----
> From: Raphaƫl Luta []
> Sent: Wednesday, May 31, 2000 10:12 AM
> Currently, if you just want a diffrent set of portlets to 
> appear on various
> occasions, you can define a PSML file with the top portlets element
> using a CardPortletController without any control. This gives you the
> ability to chose which card to display to the user and its 
> the closest thing
> we have to multiple PSML screen without modifying the code.
> An other option is to modify the Home screen so that it 
> directly which PSML description to use rather than letting the factory

> decide based on the User information.

Ok, thanks for this information. I haven't got time yet to go deep into
Jetspeed code yet, so I don't know the exact details about the current
I'm just arguing on more general level that it would make more sense (at
least to me) to reuse more the available XML technologies.

> And, of course, since we fetch the PSML files by URL, just 
> use an HTTP URL in
> the for the PSML base and configure 
> Cocoon to handle PSML extension and you're set...

Yes, this would be the cleanest solution... However, I doubt the
performance of such a solution under heavy load.

> > But don't you think that Turbine framework, in its current 
> form (being
> > _very_ ECS friendly), is a little bit limiting to Jetpseed?
> > I mean, if I want to return SAX events instead of ECS 
> element, how can I
> > achieve that?
> Why would you ever want to do this ?

I would want this to do some post-processing of the output, for example.
Otherwise I would have to parse the whole thing again.

> Cocoon is great. Turbine is great too. And yes, Jetspeed is great ;)

But I belive that the potential for Cocoon + Tubine + Jetspeed (last two
integrated with Cocoon) is much greater that each of them separately.

> Seriously allowing non-Cocoon portlets is very important in 
> Jetspeed because it
> allows existing java servlet code base to be easily migrated 
> to Jetspeed, you
> just have to write an API wrapper to iumplement the Portlet 
> API and you're set.
> This is IMO very important for Jetspeed acceptance. If you 
> only want to use
> Cocoon with Jetspeed, you can.

IMO it is possible to reuse your existing code by calling it from XSP.
Maybe even easier that writing a wrapper...

> > > > The border tag would specify the preferred way 
> (specified by portlet
> > > > developer) how the "border" of the portlet would be
> > > rendered. The user
> > > > could override these settings with some system-wide 
> theme for border
> > > > rendering. The content tag would include the XML content of
> > > the portlet
> > > > as well as stylesheets for transformation of this content
> > > to appropriate
> > > > client.
> This is covered by the use of controls and skins in the PSML file.

I'm not 100% familiar with the current implementation of skins in
Jetspeed, so correct me if I'm wrong here.
The current implementation uses skins in the way that you pass some
variables to the controller(?) and the "border" around the portlet will
be rendered using some hardcoded (ECS?) template, inserting the
variables (e.g. title color) where needed.
Using XSLT instead of this method would allow me to _easily_ change
(changing XSLT sheet) not only some variables, but the whole structure
of the "border". Using some other tags instead of <TABLE>, for
example... or putting title in the bottom instead of the top of the
portlet content (don't know why, but still)... or changing the layout of
the max/min/etc buttons...
Much more powerful and easier for the deployer, I think.

> Webmacro perfectly allows you to output any XML dialect. The 
> issue is more 
> existing HTML content reuse. Rather than using CDATA, I'd 
> rather do an HTML
> -> XHTML transform at cache level...

well, you can output XML from webmacro as string, but in order to do any
post-processing of this string you need to parse it and convert to SAX

> I don't understand. Controllers are just implementing the 
> layout strategy 
> for a set of portlets. There's an XMLPortletController which 
> use an XSL
> stylesheet to code the strategy (which is what you're arguing 
> for), its main
> limitations being speed and the need for a well-formed XML 
> document, which means
> it doesn't work with legacy HTML and some ECS code.

OK, sorry, I wasn't aware of the existence of XMLPortletController.

> I don't understand what you mean by "portlet DTD" : PSML , 
> registry or some other new DTD ?

it is just an imaginary DTD that I invented for marking up individual
portlets. I also gave some conceptual level examples of this my first

> Whan I introduced the registry my thought was that this would 
> allow me to 
> create some RemoteProxyPortlets which would use RMI, IIOP or 
> even HTTP to access remote implementations.

Interesting. As I haven't heard about this before this thread, I didn't
know about such plans. Could you explain in more detail, what you had in
mind with this?


View raw message