cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Raphaël Luta <luta.raph...@networks.vivendi.net>
Subject Re: Cocoon and Jetspeed
Date Wed, 31 May 2000 08:12:09 GMT
Neeme Praks wrote:
> 
> > You can do this now.  It just isn't implemented anywhere.  I think
> > multiple customized pages is important.  IE I want an 'Open
> > Source' and then a 'World News' page
> 
> how? As much as I have understood, the PSML files are very _static_
> currently... I cannot make "semi-personalized" pages, or can I?
>

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.

And, of course, since we fetch the PSML files by URL, just use an HTTP URL in
the Jetspeed.properties for the PSML base and configure Cocoon to handle
PSML extension and you're set...
 
> > The sitation should be a little different.  Mainly because of
> > subscription support.  If someone comes from a WAP device and wants to
> > create a customized page, Jetspeed needs to do some
> > introspection to see
> > which portlets the user can subscribe to (IE an HTML and WAP don't
> > mix).
> 
> Yep, I was thinking about this also, but I just didn't want to make my
> email any longer than it already was.
> One solution would be that portlets would store their stylesheet
> references in registry, so it would be obvious which ones support which
> media. However, this could centralize the administrative work (less an
> issue in the case of cascading registry).
> I would prefer the solution where portlets register/declare themselves
> to handle certain types of media but the actual information about the
> implementation of that support would be in the portlet and easily
> modifiable by the portlet developer (also goes together with the concept
> of "remote portlets").
> 
> So, the registry would store metadata about the portlet: where to find
> and how to access the portlet and what media types does it support. Then
> I would be up to the portlet developer to actually implement the support
> for these media types.
>

We comlpletely agree here, especially as this scheme doesn't require Cocoon.
 
> > The above would only work for Cocoon portlets.  I don't want
> > a situation
> > where we require Cocoon.  Some people might not ever care
> > about Cocoon.
> > IE the Jetspeed Admin console doesn't use Cocoon because if Cocoon
> > breaks you can't use the Admin console to fix it :)
> 
> 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 even go as far as requiring Cocoon, as I'm very fond of the
> power of XML technologies and I think they give you enormous amount of
> power for the cost of some added complexity... I find this power really
> worth the complexity but I understand that I could be a minority here...
> Then again, if we could drop the support for everything else than
> cocoon, I think that would reduce the complexity... but we wouldn't lose
> anything in functionality, only gain... (OK-OK, I'm just speculating
> here ;-)
>

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

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.

> > > 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.

> > We also need a better way to represent the rendered Portlets and their
> > HTML.  But I think this should be done with CDATA sections withing
> > portlet markup and then XSLT this into an XHTML document with Cocoon.
> 
> yep. I was also thinking about the CDATA option... but then I tought
> that I couldn't do a device dependent transformation on this afterwards.
> But if we would to this transformation before (in a device dependent
> way), then it should be ok.
> 
> But I'm still uneasy about putting in "dumb" CDATA sections... I would
> rather leave this job totally to serializers. But I understand that this
> wouldn't be possible if we want to support writing portlets with
> webmacro for example.
> 

??

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...

> I also had the idea about the overall page rendering that would also be
> implemented with similar approach. Currently it is very hardcoded, I
> even found some ECS stuff there... I understand that it is still very
> raw and it is going to be rewritten, so here is my idea for that.
> 
> The page coul bacically be something like this:
> <portalpage>
>     <portlet>
>     </portlet>
>     <portlet>
>     </portlet>
> </portalpage>
> 
> Each of the portlets would also include hints about the rendering and
> XSLT would take care of the actual conversion, replacing the need for
> "controllers" in the current sense. Does this make sense?
> 

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.

> > > The use of this kind of system would also enable the possible use of
> > > "remote portlets": XML pages (that follow the portlet DTD)
> > residing on
> > > remote server that could be rendered as portlets on local server...
> >
> > Hm.. That is interesting.  Performance would be an issue.  What
> > advantages would this give?
> 
> Jetspeed could cache this (if it is cacheable), otherwise it would be
> highly recommended to put this on some server with _fast_ connection to
> the Jetspeed server. The benefit would be the possibility to distribute
> the workload from one side. From the other side, user could code up his
> own portlet on his homepage and then add this to his personal page...
> Truly personalized content.
> 

I don't understand what you mean by "portlet DTD" : PSML , registry or some 
other new DTD ?
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.

--
Raphaël Luta - luta.raphael@networks.vivendi.net

Mime
View raw message