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
<http://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]
<mailto:[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 <http://www.szegedi.org/>
twitter: http://twitter.com/szegedi
weblog: http://constc.blogspot.com
<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]
<mailto:[email protected]>
https://lists.mozilla.org/listinfo/dev-tech-js-engine-rhino
_______________________________________________
dev-tech-js-engine-rhino mailing list
[email protected]
<mailto:[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 <http://www.lucidtechnics.com>
(p) 202.683.7486 (f) 703.563.6279
