cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject RE: [Portal] future and design questions
Date Mon, 27 Oct 2003 10:56:55 GMT
> ġURDINA Michal wrote:
> Hello!
> Right now I am in process of evaluating available portal solutions.
> Because I am big cocoon enthusiast I took a deeper look into the cocoon
> portal-fw and portal blocks.
The portal block is a newer implementation that is in general more flexibel
than the old one but currently lacks for example administration tools etc.

> I would try to summarise the main features I found when played with both
> portal-framework and portal engine. Please correct me if I am wrong:
> - both solutions aim mostly to implement portlet container capabilities
> - both solutions are quite similar from the view of sitemap configuration
and coplet features
> - coplets provide XML feeds and are realized by sitemap pipelines (local)
or by accessing any
>   source in the internet (defined by uri)
> - authentification is done by authentification-fw but this is not required
as this can be
>   replaced by other solution i.e. by container managed security
> (
Yes, but this is only true for the portal block; the portal-fw block is tied
to the
authentication-fw. Although it is possible with some trick to use a
approach with the portal-fw as well.

> - user's settings are stored in files (by means of sourcewriter
transformer) but they can
>   be persisted by any data store by means of specialized transformers
> - final HTML look is created by xsl stylesheet applied after syndicating
all coplets in layout template
> - other clients (PDA, WAP) can be handled by applying different xsl
stylesheet and targeting required markup
> - JSR-168 portlet container behaviour will be implemented in portal-engine
block to support
>   3rd party portlet implementations

> I still have some questions where I am not sure about answers:
> - what will be (or is) the main difference of current portal-framework and
new portal engine?
>   What were the main issues that caused rewrite of existing portal-fw to
portal engine?
Mainly flexibility, like choosing different authentication mechanism etc and
the JSR-168 which will only happen for the portal block (unless someone
steps in and
does it for the portal-fw as well, which would be very very tricky).

> - what exactly will be implemented from JSR-168 spec to portal engine,
what components will
>   then be still used from cocoon?
Good question, I'm wondering this myself these days :) Now, currently the
JSR-168 defines
only portlets, but not the portlet container itself (only part of the
behaviour of the
container), so it might be that the portal engine of Cocoon stays the same.
But you
will have the abilitiy to use a JSR-168 portlet instead of a pipeline.

> - what future do you see for cocoon as a portal framework when JSR-168
compliant containers
>   will come out (i.e. Jakarta Pluto) and what part of portal application
lifecycle should
>    then cocoon cover?
I honestly don't know - this is something the users will decide. Now, I hope
that the
cocoon portal engine will be JSR-168 compliant as well (soon), so when
developing portlets it
doesn't matter if you choose Cocoon or Pluto or Jetspeed or whatever. At
least that's
the theory which I think will not always be the practice: When you develop a
portlet you
need functionality and in some cases you find this functionality in your
portlet container
(in Cocoon, in Jetspeed etc.) and you will use this. From that point on
tied to that container. But the JSR-168 helps here a lot.

Anyway, personally, I think Cocoon is a good base for portal applications as
provides so many good concepts, like the avalon based architecture, the
the processing pipelines, flow, blocks (with 2.2), form handling frameworks
that make developing complex applications alot easier. And you can use all
these nice little things in your portlets as well.


View raw message