cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From burtonator <>
Subject Re: Cocoon and Jetspeed
Date Sat, 03 Jun 2000 01:11:04 GMT
Neeme Praks wrote:
> 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.

Basically.  It could also work in an inverted manner. The Portlet could
register what types of content it supports from the begining.

Of course the Cocoon portlet could handle this well.
> > 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 want to do this?  I can see this maybe being cool but
sometime in the future but I think the API would be a kludge.
> 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...

At this point Cocoon already is a requirement.  It is used everywhere
within Jetspeed.

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

So am I.  That is why I haven't done anything yet. :)
> But who says that this CDATA is actually XHTML? There is really no way
> to check that...

> 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.  However the concept of a "controller" at least form a logic
standpoint will stay.  I mean even if all the controllers are just XSP
and each with a different stylesheet the user still needs a way to
seperate this functionality.
Kevin A Burton (
Message to SUN:  "Please Open Source Java!"
"For evil to win is for good men to do nothing."

View raw message