myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject Re: Another approach to the templating problem
Date Mon, 06 Oct 2008 12:09:11 GMT
Werner Punz schrieb:
> Paul Rivera schrieb:
>> Interesting solution :)
>> I agree that the execution time of a compiler level solution will be 
>> better than an interpreted template solution.  Perhaps the only 
>> scenario that our interpreted template solution will yeild 
>> significant execution performance gain is when it caches large 
>> amounts of javascript code.  Browsing through the components, most of 
>> our large javascript code are already rendered through AddResource 
>> which is already cached.  The remaining javascript code embedded into 
>> some renderers are just not significantly large enough.
>> Do we plan to implement the same convention in myfaces-builder-plugin?
>> I.e.
>>     An abstract renderer class that c ontains the javascript template 
>> comment
>>     A concrete subclass of the one above generated by 
>> myfaces-builder-plugin that has the template comment from parent 
>> abstract class converted into java code
> Actually I would go for the concrete implementation approach. The 
> maven plugin of the compiler can take care if picking up the correct 
> files.
> It even has package rewriting possibilities (I added such a directive 
> to the grammar on thursday)
> So that people can work on the templated java files and have haven 
> compile the result into the generated sources (and still can link into 
> those if needed, due to being in a different package)...

This approach to templating is very interesting..and anything that 
improves the current StringBuffer-based approach for javascript 
generation is very nice to see! That code is really hard to work on..

What happens with breakpoints etc? This is always a tricky problem with 
templates. Generating a subclass does at least mean that breakpoints can 
be set in the "real" parent class, and the subclass contains only 
generated code (for which breakpoints are not much use). If things get 
magically compiled into a different package, then won't breakpoints set 
in the original file be ignored?

I'm also somewhat concerned about the debuggability of classes when 
templates and "normal" code are mixed in the same method. Does this work 
ok? If not, then is it possible to use the convention of creating a 
method containing *just* the magic template-comment, with the method 
parameters as the data referenced from the template?


View raw message