[
https://issues.apache.org/jira/browse/TILES-538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mck SembWever updated TILES-538:
--------------------------------
Description:
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.
Simply overriding the class is not so simple when using the
OptionsDispatchRenderer proposed in TILES-539.
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.
was:
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.
> 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. Simply overriding the class is not so simple when using the
> OptionsDispatchRenderer proposed in TILES-539.
> 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
