Comments on: Writing HTML From JavaScript http://925html.com/code/writing-html-from-javascript/ For those of us who work with the web daily. Sun, 16 Jan 2011 12:41:12 +0000 hourly 1 http://wordpress.org/?v=3.0.4 By: Eric Ferraiuolo http://925html.com/code/writing-html-from-javascript/comment-page-1/#comment-155 Eric Ferraiuolo Fri, 17 Apr 2009 16:36:47 +0000 http://925html.com/?p=326#comment-155 <strong>@Jeethu</strong> You nailed it with your point here: <blockquote>The real beauty of this is the ability to have functions which generate individual template fragments all of which could be stitched together transparently at runtime.</blockquote> With our API(s) we're also taking this approach; having all templating being a series statements consisting of [chained] method calls. This allows us to write methods which we can delegate a particular part of the rendering to. <strong>We're not doing</strong> any traditional text-based templating (e.g. PHP, JSP, or ASP— style), but we also don't have an idea of a DOM or <em>document</em> representing the data in our templates; we're taking a procedural approach with the ability to pass-off rendering tasks to delegated methods. <strong>Not having</strong> a DOM structure in memory to deal with holding the dynamic data saves resources and the need to translate between data structures. When we release our APIs publicly I'll definitely ping you to get your opinions on our approach; I feel you're interests and way of thinking in this area are lined up with ours. @Jeethu You nailed it with your point here:

The real beauty of this is the ability to have functions which generate individual template fragments all of which could be stitched together transparently at runtime.

With our API(s) we’re also taking this approach; having all templating being a series statements consisting of [chained] method calls. This allows us to write methods which we can delegate a particular part of the rendering to. We’re not doing any traditional text-based templating (e.g. PHP, JSP, or ASP— style), but we also don’t have an idea of a DOM or document representing the data in our templates; we’re taking a procedural approach with the ability to pass-off rendering tasks to delegated methods. Not having a DOM structure in memory to deal with holding the dynamic data saves resources and the need to translate between data structures.

When we release our APIs publicly I’ll definitely ping you to get your opinions on our approach; I feel you’re interests and way of thinking in this area are lined up with ours.

]]> By: Jeethu Rao http://925html.com/code/writing-html-from-javascript/comment-page-1/#comment-139 Jeethu Rao Thu, 16 Apr 2009 05:32:04 +0000 http://925html.com/?p=326#comment-139 Hi Eric, I totally agree that the example on my blog post lacks clarity. its something I'd whipped up in 5 minutes just before posting the entry. As far as the API design goes, I think it stems from my interest in functional programming and the server side language I'm using. I'm using python on the server side which is a little more amiable towards FP than say something like Java. So, the way I look at it, there are only 2 ways to do client side html templating, either render your templates as text and resort to innerHTML, or use DOM. And from what I've found, the Mochikit.DOM approach has the nicest api of all the other DOM based approches. The real beauty of this is the ability to have functions which generate individual template fragments all of which could be stitched together transparently at runtime. Now, I understand the need for a common templating system on both the client side and the server side. And I take exactly this approach (Its relatively easy to represent the whole tree in JSON) on my project. This wouldn't work for you on the server side, because Java isn't as FP friendly as it could be (the lack of closures), So that pretty much constrains you to stick to the text based templating. Hi Eric,
I totally agree that the example on my blog post lacks clarity. its something I’d whipped up in 5 minutes just before posting the entry. As far as the API design goes, I think it stems from my interest in functional programming and the server side language I’m using. I’m using python on the server side which is a little more amiable towards FP than say something like Java. So, the way I look at it, there are only 2 ways to do client side html templating, either render your templates as text and resort to innerHTML, or use DOM. And from what I’ve found, the Mochikit.DOM approach has the nicest api of all the other DOM based approches. The real beauty of this is the ability to have functions which generate individual template fragments all of which could be stitched together transparently at runtime.

Now, I understand the need for a common templating system on both the client side and the server side. And I take exactly this approach (Its relatively easy to represent the whole tree in JSON) on my project. This wouldn’t work for you on the server side, because Java isn’t as FP friendly as it could be (the lack of closures), So that pretty much constrains you to stick to the text based templating.

]]>