- Great question, Martin. Forgive me if this is getting off topic.
(Just remember it binds to JSON data! :)
Both attempt to solve similar templating issues but go about it in
different ways. This isn't meant to be exhaustive but here's a quick
The most obvious difference is purely stylistic: the syntax. TrimPath
type expressions, whereas JsonML+BST uses <%
expressions in the *.jbst templates (I've been pronouncing this
Jay-Beast" in my head, FWIW). Your preferences may vary here. Mine leans
toward the ASP/JSP style out of familiarity and abundance of syntax
highlighting tools which make it nice to work with. The pro/con of
this is subjective with valid arguments on either side I'm sure.
The next difference is a result of the chosen code block language,
literally, the expression given is wrapped as a function with a
parameter called $item providing data binding context. This means
that it can call out to utilities or other query frameworks as long as
the result of the expression is a return-able result. Typically this
ends up being strings or JsonML from a nested template. In JST, the
be learned and maintained. For example, the "capitalize" modifier
effectively calls .toUpperCase() on the result. In a JsonML+BST code
block that would be foo.toUpperCase(). JST "modifiers" are hard coded
into the system and anything new must be explicitly written for JST.
Then there are architectural differences.
JST (typically) runs the parsing in the browser, which has the pro of
being wholly client-side. If it is run on the server then the whole
point is lost and it is just another server-side scripting language.
The downside of JST parsing the raw template in the browser is that
inline via <textarea> blocks. In JsonML+BST, the original template is
just be loaded via script tags which get cached as external resources.
Both systems can lazy load via XHR, etc.
DOM dependencies, so it may run on a standalone interpreter (e.g.
Rhino). Technically, I too could port the JsonML+BST compiler to
make this impossible. My motivation to do so is low at the moment as
it wouldn't be my preference on how to run it. I'm building support
into my larger Ajax framework which automatically builds the
seamless which makes the inner (tweak-refresh-repeat) loop feel like
editing raw HTML. I find the less I fight the tools, the more I want
to do the real work.
Finally, while I don't have the real numbers in front of me, I'd
suspect that JsonML+BST keeping the hard parsing on the server keeps
the download smaller. The only two scripts needed for JsonML+BST are
JsonML2.js (currently 2.08K compacted) and JsonML_BST.js (currently
679 bytes). So in less than 3K on the client you can have a template
built out and the rest is all just the JSON data and downloading of
templates (which are based upon JsonML giving them a file size similar
When I get a chance, I plan to write up a tutorial (more than just the
example) as this is a great question that would have been easy to see
--- In firstname.lastname@example.org, "Martin Cooper" wrote:
> What would be the pros and cons of this approach when compared to the
> Martin Cooper
> On Sun, Aug 3, 2008 at 5:28 PM, Stephen M. McKamey wrote:
> > Recent discussions about JsonML (e.g.
> > http://tech.groups.yahoo.com/group/json/message/1115) and various blog
> > posts around browser-side templating (e.g.
> > that it is time to share more of what I've been working on lately.
> > One such project has been what I call JsonML Browser-Side Templating
> > (JsonML+BST). The idea is to leverage JsonML as the intermediate
> > format for automatically "compiling" templates written in an ASP/JSP
> > style to be data bound on the client. It turns out this has many
> > advantages which make for a responsive user experience. Basically,
> > you keep the compiled JsonML+BST template and the JSON data separate
> > and then data bind on the client. This allows responsive changes to
> > the view or the data.
> > This weekend I finally wrote up an overview, a little demo and
> > packaged up some code. If you are interested in more, please check
> > out a more detailed description (http://jsonml.org/BST/) and play with
> > the example (http://jsonml.org/BST/Example/).
> > Thanks,
> > smm
If there isn't any, why hasn't anyone thought of that?
Get ideas on sharing photos from people like you. Find new ways to share.
[Non-text portions of this message have been removed]
What you want does exist. See http://aptana.com/jaxer. Jaxer us a javasctipt and Ajax
server that uses spidermonkey and the mozilla dom engine to do the things you ask for
like sockets, sessions, database calls, etc... Jaxer also supports json. :)
Your link is broken. Also please have full disclosure
--- In email@example.com, "khakman" <khakman@...> wrote:
> What you want does exist. See http://aptana.com/jaxer. Jaxer us a
javasctipt and Ajax
> server that uses spidermonkey and the mozilla dom engine to do the
things you ask for
> like sockets, sessions, database calls, etc... Jaxer also supports
- On Sun, Aug 17, 2008 at 11:11 PM, Mert Sakarya <mertsakarya@...> wrote:
> If there isn't any, why hasn't anyone thought of that?
But as to the question: If you did work on Java platform, you could
use Rhino. It is very easy to integrate when running on JDK 1.6. So in
context of JVM (which can run multiple other scripting languages, not
just Java), Rhino would be a stand-alone component.
-+ Tatu +-
here is the link http://aptana.com/jaxer
On 8/18/08, Ric Johnson <RicJohnsonIII@...> wrote:
> Your link is broken. Also please have full disclosure
> --- In firstname.lastname@example.org <json%40yahoogroups.com>, "khakman" <khakman@...>
> > Mert--
> > What you want does exist. See http://aptana.com/jaxer. Jaxer us a
> javasctipt and Ajax
> > server that uses spidermonkey and the mozilla dom engine to do the
> things you ask for
> > like sockets, sessions, database calls, etc... Jaxer also supports
> json. :)
[Non-text portions of this message have been removed]