tiles-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mck <...@apache.org>
Subject "OptionsDispatchRenderer" and "Pluggable debugging around rendering"
Date Wed, 26 Oct 2011 10:43:34 GMT
In https://issues.apache.org/jira/browse/TILES-539
there's the proposal to add the class OptionsDispatchRenderer which
supports a "fallback pattern" as described in "the ultimate view"
article http://tech.finn.no/2010/11/04/the-ultimate-view/4/

OptionsDispatchRenderer has been cleaned up so that it's elegant imho
and worthy to go into trunk.
But I've had my nose so close to the grind stone on this one for so long
i'm hoping to get a little consensus and feedback before committing.

Is the syntax here appropriate and clean enough?

eg in a tiles.xml you would have

        <put-attribute name="price_label" value="/WEB-INF/tiles/vertical/${options[option_common]}/price_label.jsp"
cascade="true"/>

where $options refers to the function OptionsDispatchRenderer provides,
and option_common refers to the list of places (in preferential order)
the template can be found, eg

        <put-list-attribute name="option_common" inherit="true">
            <add-list-attribute>
                <add-attribute value="ford"/>
                <add-attribute value="car"/>
                <add-attribute value="motor"/>
                <add-attribute value="common"/>
            </add-list-attribute>
        </put-list-attribute>


Also i have a question around where this class belongs.
It can't go in tiles-request-api because it uses TilesAccess, Attribute,
and ListAttribute. For example it needs to lookup the "option_common"
mentioned above.
Is putting the class tiles-api appropriate?


This leads on to "Pluggable debugging around rendering" which is a small
improvement where i would normally think a user can simply override the
DispatchRenderer to provide their own equivalent debugging+profiling.
But OptionsDispatchRenderer wouldn't be so simple to extend in such a
manner because it doesn't yet know which template is in fact going to be
rendered. Therefore changing such debugging from extension to delegation
makes sense by adding to DispatchRenderer the DebugWrapper interface.

    public interface DebugWrapper{
        DebugWrapper start(String template, Request request) throws IOException;
        DebugWrapper end();
        void handleIOException(IOException ex, Request request) throws IOException;
    } 

This allows one to plug in a simple callback implementation. The default
DebugWrapper is a noop.

Is this wanted? It's certainly in active use by us.
Can it only be added to the DispatchRenderer?
Should it be generialised beyond just the use case of debugging
+profiling? eg something called RendererWrapper?

~mck

Mime
View raw message