You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Werner Punz (JIRA)" <de...@myfaces.apache.org> on 2008/10/04 12:21:44 UTC

[jira] Issue Comment Edited: (TOMAHAWK-1327) A proposed solution to separate javascript code from java code in Renderers

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

werpu edited comment on TOMAHAWK-1327 at 10/4/08 3:20 AM:
----------------------------------------------------------------

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!


Another thing, I did not have a look at the inside of the original interpreter,
but if you want to go with integrated templating on interpreter level
guys have a serious look at the string templates engine. It is probably leaner and easier to integrate than freemarker or to write a specialized engine just for javascripts!


      was (Author: werpu):
    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.