At 09:41 12/02/2001 +0100, you wrote:
>At 23:58 02/11/01, Raphaël Luta wrote:
>>I've just checked in Velocity templates which can be used to replace
>>the ECS screens or the JSP templates.
>>
>>I've not yet fully tested them in WML mode and there's an output bug
>>with the customizer (which outputs its content before the page) so I
>>didn't put them as the default templates right now.
>
>I think this is because the customizer uses a JSP together with the
>EcsServletElement to build the screen. The EcsServletElement doesn't do
>much during the getContent traversal, but it writes directly to the output
>stream during the toString() traversal of the Ecs tree. Now, the
>VelocityECSLayout _first_ evaluates the Ecs screen, stores the resulting
>string in the template context and _then_ evaluates the templates - as the
>EcsServletElement writes directly to the output stream, this is too late.
Actually, I'm using the VelocityOnlyLayout but I did trace the issue to the
EcsServletElement which
outputs directlt to the stream rather than sending back a buffer.
>What can we do? We could:
>1. evaluate the Ecs screen from within the template - at the place where
>it is actually needed (that's what the JSPs are currently doing with the
>EcsScreenTag). Don't know if this is possible, but I doubt it.
>2. just build up the Ecs tree, store the ConcreteElement in the context
>and do the toString at the right place in the template (that's what the
>JSP used to do in 1.3a1). Again, I don't know if Velocity permits this?
>3. patch the EcsServletElement so that it deliveres the output back to the
>calling object. This will work, we're just loosing some performance, as
>the output is streamed and buffered twice.
I think #3 is the best option. The whole current layout is done by
aggregating buffers
for building the content so we should stick to this until we have a layout
system that is
completely built around streams.
BTW, why is the customizer a Portlet ? I don't think this will stay this
way with the new Portlet API
because Jetspeed will never expose all its data structures to a Portlet.
I believe the Customizer itself should be implemented as a Turbine
sub-application, which includes
some customization content which may be generated by portlets.
--
Raphaël Luta - [EMAIL PROTECTED]
Vivendi Universal Networks - Services Manager / Paris
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
