cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From burtonator <>
Subject Re: Cocoon and Jetspeed
Date Tue, 30 May 2000 22:06:31 GMT
Neeme Praks wrote:
> Have you looked at prowler (available at
> From the information that I have got, it is trying to achieve very
> similar goal... to provide common java api to heterogeneous information
> sources...
> (I'm not aware of the licencing issues, though)

It is on my TODO list.  I will try to look at it today.
> > User personalization will be achieved with XSP.  Just a little
> > different.  We can go into this in depth if you want.
> I would love to hear what your ideas are on this...

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

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

This can already be done.  This is how RSS works.  Then the
introspection would allow for correct media detection.

> 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 

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

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

> 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 agree.  The only applications I am going to except into Jetspeed are
ECS and XSP.  Nothing else.  No JSP, no webmacro, etc.  Maybe I am wrong
but I think this is a good decision and also requires us to write good
apps.  If a situation comes up where we *really* have to have webmacro
we can talk about it but I don't forsee this....

> I find this power really
> worth the complexity but I understand that I could be a minority here...

Nope.  I do too!

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

Yes, you can :)

If you start with all WAP portlets then you have a WAP document.  :)

This is why the introspection support is necessary.  In order for
personalization app to work it needs to figure you want to create a WAP
portal and then constrain your doc to support only WAP Portlets.
> 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.

> But who says that this CDATA is actually XHTML? There is really no way
> to check that...

We can check before we get the info from the Portlet.  I mean this
support isn't in there yet but hopefully within 1.3.
> 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?

Yes.  But it would just be an XMLController :)
> > > 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. 

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.

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

OK.  That is interesting.........................  

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

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

Kevin A Burton (
Message to SUN:  "Please Open Source Java!"
To fight and conquer in all your battles is not supreme excellence;
excellence consists in breaking the enemy's resistance without fighting.
    - Sun Tzu, 300 B.C.

View raw message