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

Re: [json] JsonML+BST

Expand Messages
  • Martin Cooper
    What would be the pros and cons of this approach when compared to the TrimPath JavaScript Templates? The latter have been around for quite some time. -- Martin
    Message 1 of 8 , Aug 3, 2008
    • 0 Attachment
      What would be the pros and cons of this approach when compared to the
      TrimPath JavaScript Templates? The latter have been around for quite some
      time.

      --
      Martin Cooper


      On Sun, Aug 3, 2008 at 5:28 PM, Stephen M. McKamey <jsonml@...>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
      >
      >
      > ------------------------------------
      >
      > Yahoo! Groups Links
      >
      >
      >
      >


      [Non-text portions of this message have been removed]
    • Stephen M. McKamey
      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
      Message 2 of 8 , Aug 4, 2008
      • 0 Attachment
        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
        comparison...

        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
        syntax
        (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.

        smm

        --- 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
        some
        > 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
      • Mert Sakarya
        Hi, I know that this is not a group for Javascript, but this one is the closests one that I can ask questions. There are many Javascript interpreters around,
        Message 3 of 8 , Aug 17, 2008
        • 0 Attachment
          Hi,

          I know that this is not a group for Javascript, but this one is the closests one that I can ask questions.

          There are many Javascript interpreters around, mainly Browsers and engines like SpiderMonkey or Microsoft's JScript.
          I like Javascript a lot, but everyone has implemented Javascript for their own needs and for their own environments.
          Is there a stand-alone implementation of the language with all the libraries? I want to use Javascript as my main development platform, I want to include libraries for socket programming, Networking and accessing to the file system.
          In short I want to use Javascript like, PHP, Perl or Python but not within a specific environment.

          If there isn't any, why hasn't anyone thought of that?

          Mert















          _________________________________________________________________
          Get ideas on sharing photos from people like you. Find new ways to share.
          http://www.windowslive.com/explore/photogallery/posts?ocid=TXT_TAGLM_WL_Photo_Gallery_082008

          [Non-text portions of this message have been removed]
        • 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
          Message 4 of 8 , Aug 18, 2008
          • 0 Attachment
            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. :)
          • Ric Johnson
            Kevin, Your link is broken. Also please have full disclosure Thanks, Ric ... javasctipt and Ajax ... things you ask for ... json. :)
            Message 5 of 8 , Aug 18, 2008
            • 0 Attachment
              Kevin,

              Your link is broken. Also please have full disclosure

              Thanks,
              Ric

              --- In json@yahoogroups.com, "khakman" <khakman@...> wrote:
              >
              > 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. :)
              >
            • Tatu Saloranta
              ... You might get better answers if you asked this on a javascript mailing list. This list deals with JSON, which while inspired by javascript s syntax, is not
              Message 6 of 8 , Aug 18, 2008
              • 0 Attachment
                On Sun, Aug 17, 2008 at 11:11 PM, Mert Sakarya <mertsakarya@...> wrote:
                > Hi,
                >
                > I know that this is not a group for Javascript, but this one is the closests one that I can ask questions.
                >
                > There are many Javascript interpreters around, mainly Browsers and engines like SpiderMonkey or Microsoft's JScript.
                > I like Javascript a lot, but everyone has implemented Javascript for their own needs and for their own environments.
                > Is there a stand-alone implementation of the language with all the libraries? I want to use Javascript as my main development platform, I want to include libraries for socket programming, Networking and accessing to the file system.
                > In short I want to use Javascript like, PHP, Perl or Python but not within a specific environment.
                >
                > If there isn't any, why hasn't anyone thought of that?

                You might get better answers if you asked this on a javascript mailing list.
                This list deals with JSON, which while inspired by javascript's
                syntax, is not directly related to javascript.

                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 +-
              • Lokesh jadwani
                Kevin, here is the link http://aptana.com/jaxer Lokesh ... [Non-text portions of this message have been removed]
                Message 7 of 8 , Aug 18, 2008
                • 0 Attachment
                  Kevin,

                  here is the link http://aptana.com/jaxer

                  Lokesh


                  On 8/18/08, Ric Johnson <RicJohnsonIII@...> wrote:
                  >
                  > Kevin,
                  >
                  > Your link is broken. Also please have full disclosure
                  >
                  > Thanks,
                  > Ric
                  >
                  > --- In json@yahoogroups.com <json%40yahoogroups.com>, "khakman" <khakman@...>
                  > wrote:
                  > >
                  > > 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]
                Your message has been successfully submitted and would be delivered to recipients shortly.