(resending because of some delivery problems)
Thank you for prompt answers!
Our team can eventually choose cocoon as portal solution (we really have good and long-term experiences with cocoon). Therefore we can eventually help on developing and testing tasks and provide valuable feedback from the real world applications environment.
For this purpose we need to know additional information about the status of current implementation of portal-engine block. We would like to know, how much work is left that needs to be done. Could you please summarize those specific tasks that are left for finishing the block to be fully functional and eventually how much time they would take?
Thank you,
Michal
> -----Original Message-----
> From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]]
> Sent: Monday, October 27, 2003 11:57 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [Portal] future and design questions
>
>
> > Ď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
>
>
>
>
> __________ Informacia od NOD32 1.543 (20031024) __________
>
> Tato sprava bola preverena systemom NOD32 pre Exchange.
> http://www.eset.sk
>
>
>
