Think I worded this too strongly, as renderers also produce HTML via
Java. I just think that if you are going to have templates, it would
be great to keep them in separate files, be it *.vm for velocity or
xhtml/xml for facelets/JSF2 or what have you. These files can not only
be edited by some tools (at least facelets can, not so sure about
velocity), but they can also be changed on the fly without any java
recompilation. Java went away from servlets building HTML for this
reason and adopted JSP. I personally do not feel that going back to
more Java built HTML is going to be a great direction, but maybe that
is just me.
-Andrew
On Mon, Oct 6, 2008 at 7:07 AM, Andrew Robinson
<[EMAIL PROTECTED]> wrote:
> OMG, this would produce some insanely unmaintainable code, not to
> mention having to recompile for every little HTML change, and no way
> at all to have HTML authors help code it. Servlets were bad enough,
> but now embedding HTML in Java Comments?
>
> -0.9 for me, keep HTML in HTML maintained files would always be my
> choice. Why not go the JSF2 method for templating?
>
> As for resource handling, components could be made to be able to add
> content to the HEAD. For example, a new tr:resource component could
> communicate with the tr:document or tr:head & add content to it so as
> to ensure that CSS and JS gets added to the HEAD without the overhead
> of buffering.
>
> -Andrew
>
> On Mon, Oct 6, 2008 at 6:53 AM, Werner Punz <[EMAIL PROTECTED]> wrote:
>> Simon Kitching schrieb:
>>>
>>> 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?
>>>
>>> Regards,
>>> Simon
>>>
>>>
>> Actually the debugability is there, although you have to debug on the
>> generated code.
>> The package rewriting really can help with it, because you can keep
>> the original sources, and then debug into the generated code
>> which is hosted as the same class name in a different package!
>>
>> The goal of my approach was that you can utilize the normal java tooling
>> for everything outside of the template, but you still also should be able to
>> check the generated code and debug into it once it is compiled
>> (hence the package rewriting which is easier for ides and the users)
>>
>>
>> The main issue is however you cannot debug on the templates themselves :-(
>> Is there currently any engine which can do this?
>>
>> It probably could be possible to get debuggability into it, but I am no
>> compiler guy, it was hard enough for me to write the rewriting compiler with
>> antlr (it is nothing more than a straight to the target api rewrite
>> of the more compact template syntax)
>>
>> But in the end I do not think the generated code is so complex that
>> debugging into it is really an issue:
>>
>>
>> I will give you guys a small example how the generated code looks like:
>>
>>
>> /*TPL
>> #destpackage(pac.xxx.yyy)
>> TPL*/
>>
>> package paxxx;
>>
>> import java.util.Collection;
>>
>> public class SimpleTest2 {
>>
>> static String helloWorld = "hello world";
>>
>> private String calledMethod() {
>>
>> System.out.println("called function");
>> return "";
>> }
>>
>> public void emitTemplate() {
>>
>> String [] values = new String[5];
>> values[0] = "value0";
>> values[1] = "value1";
>> values[2] = "value2";
>> values[3] = "value3";
>> values[4] = "value4";
>>
>>
>>
>>
>>
>>
>>
>> /*TPL
>> #outputop(System.out.println)
>> This is a test for a simple embedded template
>>
>> $helloWorld
>>
>> <table>
>> <tbody>
>>
>> #each(String, $values)
>> </tr><td>$it</td></tr>
>> #end
>>
>> calling a method
>>
>> $this.calledMethod();
>>
>> this text should follow after table!
>>
>> TPL*/
>>
>>
>> }
>>
>>
>> is compiled into(please ignore the wraps enforced by the mail client and my
>> added comments!):
>>
>>
>> package pac.xxx.yyy; ---- Please note the changed package here!
>>
>>
>> import java.util.Collection;
>>
>> public class SimpleTest2 {
>>
>> static String helloWorld = "hello world";
>>
>> private String calledMethod() {
>> System.out.println("called function");
>> return "";
>> }
>>
>> public void emitTemplate() {
>> String[] values = new String[5];
>> values[0] = "value0";
>> values[1] = "value1";
>> values[2] = "value2";
>> values[3] = "value3";
>> values[4] = "value4";
>>
>> --- From here the emitted template code starts!
>>
>> System.out.println("\n This is a test for a simple embedded
>> template\n\n ");
>> System.out.println(helloWorld);
>> System.out.println("<table>\n <tbody>\n\n ");
>> Object _coll__it_1 = null;
>> if (!values.getClass().isArray()) {
>> _coll__it_1 = values;
>> } else {
>> _coll__it_1 = java.util.Arrays.asList(values);
>> }
>> java.util.Iterator _iter__it_1 = ((java.util.Collection)
>> _coll__it_1).iterator();
>> while (_iter__it_1.hasNext()) {
>> String _it_1 = (String) _iter__it_1.next();
>> System.out.println("</tr><td>");
>> System.out.println(_it_1);
>> System.out.println("</td></tr>\n ");
>> }
>> System.out.println("calling a method\n\n ");
>> System.out.println(this.calledMethod());
>> System.out.println(";\n\n this text should follow after
>> table!\n\n ");
>> }
>>
>>
>> I dont think debugging the generated code is really that much of an issue as
>> long as it can be done.
>>
>>
>>
>>
>
