If you are looking for templating alternatives have a look at StringTemplate. We have used StringTemplate as our templating engine in Hannibal, out open source web developement suite that relies on Rhino to support JavaScript handlers. Hannibal has a set of utilities that make StringTemplate and Rhino work great together for web develop. You can copy our approach, or even use Hannibal instead if it makes sense for whatever you are trying to accomplish.
You can find StringTemplate at www.stringtemplate.org. Hannibal can be found here: http://code.google.com/p/hannibalcodegenerator/ Regards, Bediako On Mon, Sep 14, 2009 at 9:34 AM, DVD <[email protected]> wrote: > Thanks. I will try. > > > Attila Szegedi wrote: > >> Well, you pretty much listed all pros and cons yourself. JavaScript is a >> general-purpose programming language, and while quite malleable, you'd still >> likely end up with a lot of syntactic cruft in your "templates" (that is, >> programs whose main purpose is to render textual output). You might have >> better luck by programmatically constructing a DOM and having it rendered, >> maybe with some library that makes constructing a DOM expressive. >> >> That is, for this particular purpose (rendering textual output) FreeMarker >> is likely more ergonomic than JavaScript, because it was expressly designed >> for exactly that purpose. That is not to say that if you apply yourself to >> the problem and write a JS library with the goal of making text output >> generating in JS as ergonomic as possible, you couldn't arrive at something >> nice. I'm sure you could. Question is, do you want to / have the resources >> to do it. >> >> That said, I don't see any showstoppers. I'd be curious to hear about your >> results if you decide to go with Rhino. >> >> Attila. >> >> On 2009.09.14., at 3:28, DVD wrote: >> >> Hello >>> , Is there a comparision for pro and cons to use freemarker versus rhino >>> (with a template unitility class) >>> as general purpose template engine? >>> rhino is quite matured but I have seen few apps/webapps are using it as >>> template engine. >>> I have been using Freemarker but feel that using Rhino is much cleaner >>> and compact, of course, >>> only need to use Javascript in web dev instead of the extra freemarker >>> mini language. >>> But I wonder if there have been showstoppers, performance issue when >>> comparing these two choices. >>> >>> Thanks >>> >>> >>> >>> >>> Attila Szegedi wrote: >>> >>>> Okay, there are several differences in the design of the two languages >>>> that make it more difficult for Rhino to work that way: >>>> >>>> 1. FreeMarker language is designed so that the execution of the template >>>> can't mutate the data you passed in. A template can define new variables >>>> that are local to an individual "process()" call, but it completely lacks >>>> language elements that would modify the passed-in ones (redefining existing >>>> names will simply result in a new local that "shadows" the original; much >>>> like JavaScript does with a prototype scope + a top level thread local >>>> scope). JavaScript, being a generic imperative programming language, >>>> doesn't >>>> live with this constraint per se. Best you can do to lower the overhead is >>>> the use-shared-global-scope-as-prototype approach that both Martin Blom and >>>> I mentioned, although as we both said, it breaks the isolation of programs >>>> from one another, but again, it shouldn't be much of a problem if your >>>> scripts don't actually go rogue on those shared objects. >>>> >>>> 2. FreeMarker's runtime execution model does define a program loading >>>> and caching mechanism, JavaScript doesn't have one, by design. In >>>> JavaScript, it's up to the host environment to provide program loading. >>>> Behind FreeMarker's "getTemplate()" call (and its [#include] directive) >>>> there's a whole loading, compiling, and memory-sensitive caching mechanism. >>>> Again, in JavaScript, and consequently Rhino, there is no such thing. You >>>> can get something similar by using existing web frameworks that support >>>> Rhino, or roll your own. However, in basic case, just using >>>> Context.compileReader() and then repeatedly calling exec() on the resulting >>>> Script object is all you need. >>>> >>>> Lots of people use the shared global scope + precompiled scripts with >>>> Rhino and are quite happy with the performance. If you implement these >>>> measures, there's good chance you'll be happy too; if not, you'll have to >>>> profile your system, identify actual bottlenecks, and then please come back >>>> to us and we'll see what we can do. But first try shared global scope + >>>> precompiled scripts. >>>> >>>> Hope that helps. >>>> >>>> Attila. >>>> >>>> -- >>>> home: http://www.szegedi.org >>>> twitter: http://twitter.com/szegedi >>>> weblog: http://constc.blogspot.com >>>> >>>> On 2009.08.31., at 1:13, DVD wrote: >>>> >>>> Hi, there. I have been using freemarker :-). I'd like to clarify if I >>>>> could do the similar way to that of freemarker >>>>> in freemarker, I could do during program init (main thread) >>>>> class Main{ >>>>> >>>>> static Configuration cfg = new Configuration(); >>>>> static cfg.setDirectoryForTemplateLoading(new File("dir")); >>>>> >>>>> static Template temp = cfg.getTemplate("test.ftl"); >>>>> } >>>>> then in any other methods (whatever thread it could be) just do >>>>> Map root = .... (fillup data model) >>>>> Main.temp.process(root,....) >>>>> >>>>> I have not seen an example for rhino to do this way. The template >>>>> would only do normal template processing. >>>>> no fancy stuff. Can Rhino have a mode to do this way with thread >>>>> safety gurranteed. >>>>> Thanks very much. >>>>> >>>>> >>>>> Attila Szegedi wrote: >>>>> >>>>>> What other template engines work this way? (I'm one of primary >>>>>> developers of FreeMarker, and the concept doesn't strike me as familiar >>>>>> there :-) ) >>>>>> >>>>>> Anyway, this too is possible. In one context (say, the one that also >>>>>> compiles the script, although this is not strictly necessary): >>>>>> >>>>>> globalScope = cx.initStandardObjects(); >>>>>> >>>>>> then in the repeated contexts (i.e. those handling HTTP requests), >>>>>> just do: >>>>>> >>>>>> ScriptablelocalScope = cx.newObject(globalScope); >>>>>> localScope.setPrototype(globalScope); >>>>>> >>>>>> although you will likely also need to create the contexts through a >>>>>> context factory that returns true for hasFeature(FEATURE_DYNAMIC_SCOPE) >>>>>> if >>>>>> you do that. Anyway, you can try without that actually, but if you run >>>>>> into >>>>>> weird behaviour with properties missing in the global scope. Also, be >>>>>> aware >>>>>> that now the global scope became shared mutable state between threads. If >>>>>> your JS scripts are good citizens, and don't do fancy stuff like redefine >>>>>> the Array constructor or such (that is, treat the stuff in global scope >>>>>> as >>>>>> immutable) then you'll be fine. >>>>>> >>>>>> Attila. >>>>>> >>>>>> On 2009.08.30., at 16:11, DVD wrote: >>>>>> >>>>>> What I would expect is Rhinoe would have a mode that allows the >>>>>>> following >>>>>>> (it is ok to disable some features such as concurrentcy within JS to >>>>>>> make it happen) >>>>>>> >>>>>>> public static context = Context.enter(); public static >>>>>>> globalCompiledScript = context.compile(script) >>>>>>> public static globalScope = ..... >>>>>>> (the above is done in main thread , not threadlocal, just done once >>>>>>> during program init) >>>>>>> >>>>>>> then in each thread, >>>>>>> localScope = ..... (localscope backdropped by globalscope) >>>>>>> globalCompiledScript .exec(localscope) >>>>>>> >>>>>>> Most other template engines work this way. would it be possible for >>>>>>> Rhino? >>>>>>> >>>>>>> >>>>>>> Martin Blom wrote: >>>>>>> >>>>>>>> DVD wrote: >>>>>>>> >>>>>>>> Thanks. I have many threads come and go instead of a fixed pool so >>>>>>>>> the overhead is big. >>>>>>>>> I hope rhino to have a mode that would allow a preloaded/compiled >>>>>>>>> JS >>>>>>>>> (template) to be executed repeatedly >>>>>>>>> with different scope (essentially a template engine ) to produce an >>>>>>>>> output string. >>>>>>>>> the template would run in only single thread before producing the >>>>>>>>> output. >>>>>>>>> Equivalent of Freemarker engine. Would it be possible? Or because >>>>>>>>> of >>>>>>>>> this issue, >>>>>>>>> Rhino has not been widely used as template engine for Java, >>>>>>>>> compared >>>>>>>>> to others like >>>>>>>>> velocity/freemarker. >>>>>>>>> >>>>>>>>> This should definitely not be a problem. >>>>>>>> >>>>>>>> In ESXX, for instance, I have an ExecutorService with a >>>>>>>> ThreadFactory >>>>>>>> that enters/leaves a JS context as part of the thead's lifespan. >>>>>>>> These >>>>>>>> threads then handles requests by calling functions in a JS >>>>>>>> application >>>>>>>> scope. The application scope is set up once when the JS app is >>>>>>>> loaded, >>>>>>>> by executing the pre-compiled JS scripts files (using >>>>>>>> Context.compileString()) with it. >>>>>>>> >>>>>>>> If you want your requests to execute isolated from each other, you >>>>>>>> can >>>>>>>> simply create a new global scope and execute the compiled script >>>>>>>> with it >>>>>>>> for each request. >>>>>>>> >>>>>>>> (It's also possible to mix these strategies by having a shared >>>>>>>> top-level >>>>>>>> scope and using the prototype chain to add per-request scopes (needs >>>>>>>> Context.FEATURE_DYNAMIC_SCOPE, I think), but I could never quite get >>>>>>>> this to work properly, since in ESXX, I need to allow arbitrary Java >>>>>>>> threads to call JS functions, and there were some issues that I have >>>>>>>> forgotten about now.) >>>>>>>> >>>>>>> _______________________________________________ >>>> dev-tech-js-engine-rhino mailing list >>>> [email protected] >>>> https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino >>>> >>> > _______________________________________________ > dev-tech-js-engine-rhino mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino > -- Bediako George Partner - Lucid Technics, LLC Think Clearly, Think Lucid www.lucidtechnics.com (p) 202.683.7486 (f) 703.563.6279 _______________________________________________ dev-tech-js-engine-rhino mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
