Stan Pinte wrote:
>
> PS: rafael, I read your post "Re: VelocityPortlet vs
> TurbineScreenPortlet" of the 1st of august, but...
>
> > (the main one that the TurbinePortlet *must not* try to change the
> layout/template
> > etc... because that will mess with the Jetspeed engine as such).
>
> and I am of course changing the templates using
> setTemplate("newTemplate.vm") calls in my Actions or Screens...
>
> >Now, VelocityPortlet is just a Portlet that allows you to associate
> one or
> >several velocity Portlets with one action that is used to populate
> content
> >on demand. You can not use it as a "Turbine application front-end"
> directly
> >but if you have a modern Turbine app (pull + template) you can write
> >a Portlet view of this app with the VelocityPortlet in a few seconds...
>
> I looked at the VelocityPortlet...seems nice, but I don't see nowhere in
> the code that the VelocityPortlet calls my Screen classes having the
> same name as the template ( like Turbine does ). Do you see my point?
>
Yes, but Screens are being phased out of Turbine and I don't plan to
support them directly with the VelocityPortlet which is rather designed to
use a Pull methodology.
Mapping screen to template in Jetspeed is not a trivial task because the
template used is not directly correlated to the portlets seen, however you
can easily modify the VelocityPortlet to look at the Portlet template name
and try to execute a Screen class based on this name, basically duplicating
what Turbine does during its layout phase.
If you check out the VelocityPortlet code, you'll see that it executes an
Action based on init parameters, you can modify this to execute a screen
based on template value.
You'll also need to modify many default context objects like $link in order
to separate your "Turbine parameters" from the Turbine parameters used by
Jetspeed: if you use a $link.setPage(...) in your portlet without precautions,
you'll change the global template of Jetspeed and not simply the template
displayed by your portlet.
Also note that some features like setRedirect() won't work, because your
generated content is aggregated into another one and thus you can't control
the complete response flow.
> Has someone thought about modifying this class so that it does it? I
> have the feeling that such class must already exists in the Turbine
> source, as the job is the one that the turbine engine does when
> generating a screen for a specific page...
>
Check the DefaultLayout and DefaultPage classes in Turbine 2.1
--
Raphael Luta - [EMAIL PROTECTED]
Vivendi Universal Networks - Paris
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
