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 contains 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 Best Regards, Paul Rivera --- On Sun, 10/5/08, Leonardo Uribe <[EMAIL PROTECTED]> wrote: From: Leonardo Uribe <[EMAIL PROTECTED]> Subject: Re: Another approach to the templating problem To: "MyFaces Development" <[email protected]> Date: Sunday, October 5, 2008, 9:09 AM On Sat, Oct 4, 2008 at 3:57 AM, Werner Punz <[EMAIL PROTECTED]> wrote: Hello everyone I have developed another approach to the templating problem. Most solutions which tried to tackle the approach worked on interepted template level: https://issues.apache.org/jira/browse/TOMAHAWK-1327 I did another approach the last few weeks I made an embedded templating compiler for java I did it due to the inherent speed hits we have by using existing templating solutions and due to the fact that I want to parts of the code in the dojo components project over to templates to increase readability: What I did was to develop with antlr some mini velocity which can be embedded into java via special comments. The advantage is, that you simply can embed your templates inline via a comment flag you can work on valid java code while still having your templating code in one place. It is more or less an inverse scriptlet system to be usable from java. I will give an example public class SimpleTest { static String helloWorld = "hello world"; private calledMethod() { System.out.println("called function"); } 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*/ } } This code is then basically rendered against the output System.out.println (other output directives can given via an #outputop(<output directive>) command in the template! I know this approach is not academic due to no MVC and due to extended control commands like iterations and selections within the language and the possibility to call external methods within the template. The advantage however is, the strings are rendered straight into output directives almost like handwritten code, by avoiding introspection I can gain similar speeds (however with the disadvantage that you have to pass a casting datatype into the #for and #each loops) But if the community would like it I would merge it into our utils project next week. Otherwise I can drop it somewhere else. I would like to see this in myfaces-builder-plugin, so this feature can be extended properly in the future. This could improve the way we write some component parts, so it is most welcome. Werner
