tiles-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antonio Petrelli <antonio.petre...@gmail.com>
Subject Re: "OptionsDispatchRenderer" and "Pluggable debugging around rendering"
Date Wed, 26 Oct 2011 11:42:44 GMT
2011/10/26 Mck <mck@apache.org>

> 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?

Interesting, but I think it should go into tiles-extras.

> 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?

For debugging I'd prefer a publish-subscribe pattern. So there will be a
registration phase, in which listeners are attached to the renderer, and at
runtime listeners are called consequently.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message