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 13:06:46 GMT

Sorry for such a delay in answering but my daily job kept me too
occupied to write any "in-depth" responses ;-)

> -----Original Message-----
> From: burtonator []
> Sent: Wednesday, May 31, 2000 12:07 AM
> To:;
> Subject: Re: Cocoon and Jetspeed
> Basically an XSP app that takes in an existing PSML document 
> and renders
> a UI for it.   You would configure your PSML and then save it back to
> disk.  That is a lot less complicated than it really is.  It 
> is a large
> job but it needs to be done.

well, I think this makes things much less flexible. My suggestion would
still be to use cocoon when reading the personal PSML file: if you store
profiles in static files (as we have right now) you can use XSP (or
whatever other cocoon method ) to return them as they are; however, I
have the option to use XSP to generate the file from some other data
source instead.

How it could actually look like:
you have the default.psml file that is actually an XSP page. 
If anonymous user requests this page, XSP returns the default.psml file
from the filesystem.
If authenticated user requests this page, XSP returns the user personal
page from the filesystem (stored as username.psml, for example).

At the same time, this doesn't limit the developer to the default
storage (filesystem). Instead, I could replace the logic in the XSP to
get the data from database (or any other datastore) instead.

Simple and powerful, isn't it?

> No.  The engine is smart enough to handle static files that 
> change.  If
> you modify default.psml while Jetspeed is running it will rebuild your
> PSML page for you.

But I mean personalization-on-the-fly, not that I sometimes change the
file and the _all_ users see these changes. What I mean is that the
content is customized for _each_ individual user by the means of XSP

>  We really just need to write a PSML 
> content provider
> and abstract its data representation so that you can use a 
> file or a DB.

well, then we would be limited to file and DB, until somebody adds some
other "content provider". As Stefano also pointed out, we could _reuse_
Cocoon's generating capabilities for this, instead of reinventing the

> Do you mean the deployer?  I think that by default a Portlet 
> should have
> the capability to support certain media types but it is up to its
> deployment to determine if it can actually render these at runtime.


> > (also goes together with the concept
> > of "remote portlets").
> I didn't follow.

I mean the case of storing stylesheet ref's in the registry vs. storing
only capabilities in the registry and storing actual stylesheet ref's
with the portlet.
The second case is more preferable for the remote portlets idea: the
portlet resides on remote server and the owner of that portlet can
easily change the stylesheet ref's that are used for actual
transformation of the XML portlet into target media (and all the
Jetspeed servers that use that portlet would automatically update the
rendering logic). In the first case the owner would have to notify all
the Jetspeed servers that use his portlet about the change of

> > 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.
> I see it the other way around, but yes.  

Other way around?

> > I mean, if I want to return SAX events instead of ECS 
> element, how can I
> > achieve that?
> ClearElement.  You can put whatever you want in there.  This 
> is how the
> FileServerPortlet works, it just reads in any file and shoves 
> it into a ClearElement.

well, but here we arrive to the same problem of "dumb" string data: in
order to do any sensible post-processing, Cocoon would have to parse the
string (in ClearElement) and convert it to SAX events. Of course, this
is a problem only if we would want to do some post-processing on the
contents of ClearElement.

> > 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 ;-)
> The other issue is the current Cocoon impl.  Honestly, the Cocoon
> integration isn't something that I am proud off.  It forces us to have
> RunData everywhere (which is a serious technical problem within the
> core, IE if you wish to kick of a Thread you need to bring the RunData
> with you :().  When Cocoon 2.0 ships (still 6 months away) we 
> will be in a better place but until then we are still in a kludgy env

I also think that Cocoon 2 will be the version of Cocoon that I would
like to integrate Jetspeed with.
The time delay is of course a problem, but I think we can influence the
design of Cocoon 2 by taking the issue of integrating Jetspeed early in
the process.

Meanwhile I'll probably have to use the current state of Jetspeed to
deliver a beta version of the product I'm working on. And then port it
to Cocoon2/Jetspeed when it is finally there.

> > 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.
> We could do schema validation on the resulting XML document.  
> IE PSML ->
> WAP Portlets -> combined WAP document -> schema validation.

well, but for this you would have to re-parse the CDATA sections...

> I thought this is what you were hinting at :) 
> There is a document for doing this with JServ.  It really 
> should be done
> at the Servlet engine level.

ok, maybe. I'm not very familiar with servlet programming _yet_.

> There is a security hole here in that if I put some Javascript into my
> portlet and then served a portlet from, the
> person could get passwords from cookies on the 
> domain
> :(

Yes, that could be an issue... Then you would have to give the user a
_serious_ warning that this can be major security hole and that he
should only use portlets from trusted sources.

> Still an interesting idea though...  But maybe it should just be
> something like RSS or XMLRPC.  I mean essentially a Remote 
> Portlet would
> only be data communication and nothing else.  

But this takes away much of the simplicity and flexibility, doesn't it?
With remote portlets, a user could put together his own simple portlet
on his homepage by following a few quite simple rules... without a need
to learn the complex syntax of RSS or XMLRPC.


View raw message