Loading ...
Sorry, an error occurred while loading the content.

1148Re: JsonML+BST

Expand Messages
  • Stephen M. McKamey
    Aug 4, 2008
      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
      JavaScript Templates (JST) uses "${p.alert|default:""|capitalize}"
      type expressions, whereas JsonML+BST uses <%
      $item.data.foo.toUpperCase() %>
      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,
      JsonML+BST uses plain-old-JavaScript as its scripting language. Quite
      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
      expressions themselves are not JavaScript and therefore yet another
      (http://code.google.com/p/trimpath/wiki/JavaScriptTemplateSyntax) must
      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.
      In JsonML+BST, you can make any JavaScript call which is available.

      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
      since it is neither XHTML nor JavaScript it must be initially loaded
      inline via <textarea> blocks. In JsonML+BST, the original template is
      compiled at build-time into valid JavaScript. This means that it can
      just be loaded via script tags which get cached as external resources.
      Both systems can lazy load via XHR, etc.

      A pro for JST is that the core is all written in JavaScript without
      DOM dependencies, so it may run on a standalone interpreter (e.g.
      Rhino). Technically, I too could port the JsonML+BST compiler to
      JavaScript since it doesn't use any fancy library calls which would
      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
      templates. Creating templates and getting the JavaScript output is
      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
      to HTML).

      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
      with code.


      --- In json@yahoogroups.com, "Martin Cooper" wrote:
      > What would be the pros and cons of this approach when compared to the
      > TrimPath JavaScript Templates? The latter have been around for quite
      > time.
      > --
      > 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.
      > > http://ejohn.org/blog/javascript-micro-templating/) have made me think
      > > 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
    • Show all 8 messages in this topic