Santiago Gala wrote:
> >
> > Santiago, can you take care of this since you did all the work on the
> > alternate branch ?
> >
>
> Sorry, I missed it for some time.
>
> Just a question. Does anybody know the procedure for doing this? I could work out,
> but I would prefer that people with more experience in cvs tells me if there is a
> standard way to switch branches.
>
> I will do it as soon as I know that I will not break everything...
>
As far as I know, you can't break things with CVS... ;)
> Also, a question to Kevin. Is there a set of changes in HEAD that can be merged
> with current branch without breaking code?
>
> >
> > > > This way new people interested in Jetspeed can check out a working
> > > > version of the product.
> > > >
> > > > - update our dependency on Turbine to benefit from the new
> > > > developments of the framework (new ACL model, templating, etc...)
> > > >
> > > > I'll work on the template model of Turbine to see if we can upgrade
> > > > the PSML and rendering implementation to use templates without
> > > > breaking the Portlet API.
> > >
> > > Yeah.. I haven't had a chance to look at the new Turbine stuff.
> > >
> >
> > I've not yet looked at the new ACL model since it's not in the main branch but
> > I gave some thoughts on the template issue and there are several ways of
> > implementing this in jetspeed depending on our goals:
> >
> > - Do we want to keep existing Portlets unchanged by this addition ?
> > - Do we want to be able to mix templated and non templated Portlets in
> > the same layout ?
> > - Which templating system are we planning to support ?
> >
> > I'd answer yes, yes and Webmacro/Velocity/XSLT.
>
> +1. I think we should offer three different ways to write portlets in the long
> term:
>
Actually, I was talking short term improvements to the current Jetspeed code.
> 1. ByteStream based (HttpRequest/Response), for integration of jsp and servlets.
> Templates (Velocity...) are really a specialization of this solution. We have some
> code samples that could come to the codebase.
> 2. Object Tree based (ECS, DOM?, ...). That is our current way, even as Turbine is
> deprecating it.
> 3. XML event Stream based (Cocoon2). This is the most promising way I see in the
> long term, but currently is simply not in place in Jetspeed.
>
> >
> > I think I'll try a base implementation of such a system by
> > subclassing the Portlet interface into a TemplatePortlet interface and provide
> > alternative JetspeedLayout.
> >
>
> +1. I imagine you will follow the track of the Turbine Template Screens.
>
Yes, I'll keep the ConcreteElement as container for a template output so that
we can easily mix template aware and non template aware Portlets. Also
collecting all the Portlet outputs in a container element allows for some
optimizations since you can multi-thread the portlet content generation and
serialize only when writing to the OutputStream.
--
Rapha�l Luta - [EMAIL PROTECTED]
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
