> Ď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 > (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106703524221219&w=2) 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 different 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 implementing 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 you're 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 it provides so many good concepts, like the avalon based architecture, the sitemap, the processing pipelines, flow, blocks (with 2.2), form handling frameworks etc that make developing complex applications alot easier. And you can use all these nice little things in your portlets as well. HTH Carsten
