[
https://issues.apache.org/jira/browse/TILES-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mck SembWever updated TILES-538:
--------------------------------
Component/s: (was: tiles-core)
tiles-api
> Pluggable debugging around rendering
> ------------------------------------
>
> Key: TILES-538
> URL: https://issues.apache.org/jira/browse/TILES-538
> Project: Tiles
> Issue Type: Improvement
> Components: tiles-api
> Reporter: Mck SembWever
> Assignee: Mck SembWever
> Fix For: 3.0.x
>
> Attachments: TILES-538.patch
>
>
> At finn.no we're using a custom TemplateAttributeRenderer (DispatchRenderer
> in tiles-3).
> One of the customisation we have is customised debugging around each template
> rendering. For us this customised debugging does:
> - print "<!-- start insertAttribute /template-name/ -->" before rendering
> - print "<!-- end insertAttribute /template-name/ /render-time-ms/ -->"
> after rendering
> - maintains a tree of templates rendered which is printed out as a comment
> at the bottom of the html, eg
> /WEB-INF/tiles/template/main_template.jsp (20ms)
> /WEB-INF/tiles/fragment/header.jsp (2ms)
> /WEB-INF/tiles/fragment/body.jsp (16ms)
> /WEB-INF/tiles/fragment/left_menu.jsp (6ms)
> /WEB-INF/tiles/fragment/content.jsp (10ms)
> /WEB-INF/tiles/fragment/footer.jsp (2ms)
> We find this useful for finding relevant jsps quickly, and for finding
> performance problems within the presentation layer in development and test
> environments. And I've seen something similar in other websites.
> Would it make sense to introduce such an api into DispatchRenderer so to make
> it possible to plug such debugging in rather than having to override the
> class.
> I'm not entirely sure myself so throwing this out there. One problem i can
> see if that this only works for the DispatchRenderer, although this is
> intended to be taken advantage of
> TilesContainerFactory.createTemplateAttributeRenderer(..) where it is
> specified as the default renderer.
> {code}
> public class DispatchRenderer implements TypeDetectingRenderer {
> public interface DebugWrapper{
> DebugWrapper start(String template, Request request) throws
> IOException;
> DebugWrapper end();
> void handleIOException(IOException ex, Request request) throws
> IOException;
> }
> private final DebugWrapper debugwrapper;
> public DispatchRenderer(){
> this.debugwrapper = new DummyDebugWrapper();
> }
> public DispatchRenderer(DebugWrapper debugWrapper){
> this.debugwrapper = debugWrapper;
> }
> /** {@inheritDoc} */
> @Override
> public void render(String path, Request request) throws IOException {
> if (path == null) {
> throw new CannotRenderException("Cannot dispatch a null path");
> }
> try{
> debugwrapper.start(path, request);
> request.dispatch(path);
> }catch(IOException ex){
> debugwrapper.handleIOException(ex, request);
> }finally{
> debugwrapper.end();
> }
> }
> /** {@inheritDoc} */
> public boolean isRenderable(String path, Request request) {
> return path != null && path.startsWith("/");
> }
> private static final class DummyDebugWrapper implements DebugWrapper{
> @Override
> public DebugWrapper start(final String template, final Request
> request) throws IOException {
> return this;
> }
> @Override
> public DebugWrapper end() {
> return this;
> }
> @Override
> public void handleIOException(IOException ex, Request request) throws
> IOException {
> throw ex;
> }
> }
> }
> {code}
> The handleIOException(..) also allows behaviour to be configurable against
> environment. For development and test we re-throw the IOException, but in
> production we ignore it and write a warning as a html comment into the
> response. This makes the "ignore" attribute to the template more of an assert
> rather than forced.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
