Hi,

Jason suggested that a more detailed explanation of what is going on
here might be useful, so based on my understanding of turbine 3, here we
go:

> The first is that Renderer seems to define many methods which are not
> used. The role of renderer is to help Valves render templates, however
> it defines a number of unused methods which are outside of that
> responsibility. For clarity I think it would be good to eliminate these
> methods.

In turbine 3, processing of requests is being done by a catalina style
pipeline consisting of a series of valves responsible for discrete
portions of this processing. The only pipeline implementation currently
in turbine 3 is being called the turbine classic pipeline, and is meant
to mimic as closely as possible the flow of request processing in
turbine 2. The valve responsible for rendering a template is
DefaultTargetValve. 

This valve creates an instance of Renderer to do the rendering of the
template. Using another class for the rendering allows the renderer to
be placed on the context, and its functionality exposed to templates
(further explanation below). 

There is also a subclass of DefaultTargetValve called DirectTargetValve,
which uses DirectRenderer to render the template directly to the servlet
output stream (it is passed directly to the template engine service)
rather than building the output from strings as in turbine 2.

> Second, I feel it is cumbersome to be required to include the rundata on
> each method call. Since a renderer is linked to a request it can easily
> maintain a reference to its rundata. This allows simpler calls in
> templates.

The renderer is available from the template context as $renderer. It is
used to do any rendering of other templates from within a template. Thus
where in a turbine 2 layout you would have:

        $navigation.setTemplate("/default_top.vm")
        $screen_placeholder
        $navigation.setTemplate("/default_bottom.vm")

In the current turbine 3 you would have:

        $renderer.render("navigations", $data, "/DefaultTop.vm")
        $renderer.render("screens", $data, $template )  
        $renderer.render("navigations", $data, "/DefaultBottom.vm")

However the data argument is not needed, and if/when the proposed patch
is applied you would have:

        $renderer.render("navigations", "/DefaultTop.vm")
        $renderer.render("screens", $template)
        $renderer.render("navigations", "/DefaultBottom.vm")

Which is a bit simpler from a designer's perspective. However it
requires that layouts in existing turbine 3 applications will need to be
changed to use the new syntax. 

Hopefully that clears up any confusion or curiosity, but please correct
me if I'm wrong or let me know if any further clarification is needed.

Thanks,
James



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to