[ 
https://issues.apache.org/jira/browse/TOMAHAWK-1327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12636804#action_12636804
 ] 

Werner Punz commented on TOMAHAWK-1327:
---------------------------------------

Well I dont think an interpreted template solution really is the way to go,
The issue i have with the token approach is simply that it is pretty fast for 
simple grammars
(but probably still slower than emitting real code unless you have huge 
codeblocks you can cache
which normally is not there on component level)
but as soon as the grammar becomes more complicated the speed hit is 
significant because you have
to traverse on the tree by walking up and down the tree nodes instead of just 
emitting linear code.


 I did a compiler
to emit the code into plain old java which is probably the easiest solution to 
integrate and the one
closest to the original speed!


example

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*/


    }

Results in:

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";
        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 it_1_coll = null;
        if (!values.getClass().isArray()) {
            it_1_coll = values;
        } else {
            it_1_coll = java.util.Arrays.asList(values);
        }
        java.util.Iterator _iter_it_1 = ((java.util.Collection) 
it_1_coll).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        ");
    }


Other output directives also can be used (ie. the printwriter api for 
components)
the solution would be jsf agnostic, and the end result is pretty close to what 
you would emit with original code, but still would keep the original template 
formatting, which also would result in something easier for the eye on the 
emitted code side!


> A proposed solution to separate javascript code from java code in Renderers
> ---------------------------------------------------------------------------
>
>                 Key: TOMAHAWK-1327
>                 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1327
>             Project: MyFaces Tomahawk
>          Issue Type: New Feature
>            Reporter: Paul Rivera
>            Priority: Minor
>         Attachments: freemarker_impl.rar, simple_impl1.rar, simple_impl2.rar, 
> template-core.zip
>
>
> In our current implementation of component renderers, javascript code is 
> generated using ResponseWriter methods inside the renderer. Although, when 
> the embedded javascript code gets too lengthy, the renderer code can become 
> hard to read and debug.
> The proposition is to provide developers with a tool that separates 
> javascript code from the renderer code and move it into template files. This 
> solution is similar to how TemplateRenderer handles HTML content.
> Attached above is the JavascriptTemplateEncoder implementation that uses 
> FreeMarker.  More information about JavascriptTemplateEncoder and its 
> performance in the PDF files inside the zip.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to