Suggestion for a template language

[Tero Piirainen]

First: I'm really impressed with nodejs. Thank you guys! This will
change the world. Now that we have a fresh start for an ideal server
side framework I'm proposing here a syntax for an ideal template
language. Here is an example

<!-- html "template" -->
<div id="example">
<h2>Title</h2>

<p>Something here</p>

<p class="foo"></p>

</div>

And here is the JS that will make dynamic changes to the template

// the JavaScript
{
'#example': {
h2: 'My updated title',
p: 'My content',
'.foo': gerSomeDataByScripting()
}
}

So what is so special about this

1. the template is pure HTML no special markers or template syntax
2. JavaScript uses a query syntax similar to jQuery (sizzle) to alter
the template
3. JS feels natural: mimics CSS and jQuery + the power of V8

Thougts?

[Hagen]

Actually, that is a nice idea, however:

• let others decided if your thoughts are "ideal". People like choice and always will differ.
• there is currently no HTML parser available to node. I'd love webkit's to be included in the future, but right now, that's a total show stopper to your idea.

@Ryan: Any idea, how difficult it would be to include webkit's html parser into node.js? Most of the necessary code must be in v8 because of chrome, right?

> --
>
> You received this message because you are subscribed to the Google Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com.
> To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/nodejs?hl=.
>
>
>



--
Dissertations are a successful walk through a minefield -- summarizing them is not. - Roy Fielding

[Ryan Dahl]

On Mon, Nov 23, 2009 at 10:50 AM, Hagen <six...@gmail.com> wrote:
> Actually, that is a nice idea, however:
>
> let others decided if your thoughts are "ideal". People like choice and
> always will differ.
> there is currently no HTML parser available to node. I'd love webkit's to be
> included in the future, but right now, that's a total show stopper to your
> idea.
>
> @Ryan: Any idea, how difficult it would be to include webkit's html parser
> into node.js? Most of the necessary code must be in v8 because of chrome,
> right?

I will be putting Jeff Smick's binding of libxml2 into the
distribution at some point.

[Hagen]

I will be putting Jeff Smick's binding of libxml2 into the
distribution at some point.

Please correct me if I am wrong, but libxml2 does not have an HTML mode. Having libxml2 is cool and all, but having a true HTML parser is a whole different beast. Believe me, I tried implementing a web crawler, parsing HTML is a royal pain if you don't have access to a browser's parser. 

[Ryan Dahl]

Sounds like a reasonable feature to have. Maybe using _why's parser
from Hpricot is better / less entangled than webkit.

[Hagen]

Hpricot is cool. The only reason I suggested webkit's is the existing integration of that parser and v8 somewhere available in chrome.

Otoh, having a DOM would make integrating server-side and client-side code even more trivial. E.g. an implementation of the template engine spawning this thread could reuse jQuery code for selecting the correct node.

--

You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=.

[Felix Geisendörfer]

John wrote a HTML parser which might run without any modifications in
node: http://ejohn.org/blog/pure-javascript-html-parser/

The DOM related stuff obviously will not work, but parser itself is
probably worse looking at.

A CSS / selector based templating engine is a very powerful idea. How
would you handle loops and iterations?

-- Felix Geisendörfer aka the_undefined

PS: Great to see you here Tero, Flowplayer / jQuery Tools rock ; )

On Nov 23, 11:15 am, Hagen <six...@gmail.com> wrote:
> Hpricot is cool. The only reason I suggested webkit's is the existing
> integration of that parser and v8 somewhere available in chrome.
>
> Otoh, having a DOM would make integrating server-side and client-side code
> even more trivial. E.g. an implementation of the template engine spawning
> this thread could reuse jQuery code for selecting the correct node.
>
>
>
>
>
> On Mon, Nov 23, 2009 at 11:09 AM, Ryan Dahl <coldredle...@gmail.com> wrote:
> > On Mon, Nov 23, 2009 at 11:04 AM, Hagen <six...@gmail.com> wrote:
> > >> I will be putting Jeff Smick's binding of libxml2 into the
> > >> distribution at some point.
>
> > > Please correct me if I am wrong, but libxml2 does not have an HTML mode.
> > > Having libxml2 is cool and all, but having a true HTML parser is a whole
> > > different beast. Believe me, I tried implementing a web crawler, parsing
> > > HTML is a royal pain if you don't have access to a browser's parser.
>
> > Sounds like a reasonable feature to have. Maybe using _why's parser
> > from Hpricot is better / less entangled than webkit.
>
> > --
>
> > You received this message because you are subscribed to the Google Groups
> > "nodejs" group.
> > To post to this group, send email to nod...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > nodejs+un...@googlegroups.com<nodejs%2Bunsu...@googlegroups.com>
> > .

[choonkeat]

Hi Felix,

Loops and iterations should be the only mode of operation. Inspired by jQuery, I'd implemented the unobtrusive server-side scripting idea for Ruby http://tinyurl.com/hquery and it is currently being used in production at slideshare.net. AFAIK, designers love it.

Instead of a data format,

{
 '#example': {
   h2: 'My updated title',
   p: 'My content',
   '.foo': gerSomeDataByScripting()
 }
}

I'd actually vote for more vanilla javascript code

dom.select('#example').each(function(ele) {
  ele.select('h2').text("My updated title");
  ele.select(p').text("My content");
  ele. select('.foo').html(gerSomeDataByScripting());

});

In Ruby, the syntax is very nice to work in & maintain. However, the runtime gets pretty slow. hquery has to compile down to conventional <%= "ERb" %>  for production use. This JS version might need similar approach

--
choonkeat

2009/11/23 Felix Geisendörfer <fe...@debuggable.com>

To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.

[Rakesh Pai]

Just some thoughts on a templating system:

1. Shouldn't be restricted to HTML, since it can be used for xml/json/other formats as well.

2. Should not be so complex as have it's own language. If we could use inline JS in the template as the templating language, it would be ideal.

3. Should support conditionals and loops.

4. Should on no account be the *only* templating language to pick from. If someone doesn't like the templating language, it should be trivial to use another system.

5. Should support partial fragments and includes. The templating system shouldn't itself enforce well-formed-ness of the structure of the template. (eg, strict xml parsing).

6. Populating the template should be as simple as binding it with a data object or two. The templating system figures out the rest.

These are my 2c. Do you disagree? Do you have anything to add?

Regards,

Rakesh Pai

2009/11/23 Felix Geisendörfer <fe...@debuggable.com>

To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/nodejs?hl=.

--
Rakesh Pai
Mumbai, India.
rakes...@gmail.com
http://piecesofrakesh.blogspot.com/

[Onne]

My personal preference is:
http://json-template.googlecode.com/svn/trunk/doc/Introducing-JSON-Template.html

which you can just use today, since it has zero non-js dependencies.

As Rakesh Pai said, it shouldn't be restricted to html.

regards,
-Onne

> > <nodejs%2Bunsu...@googlegroups.com<nodejs%252Bunsubscribe@googlegroups. com>

>
> > > > .
> > > > For more options, visit this group at
> > > >http://groups.google.com/group/nodejs?hl=.
>
> > > --
> > > Dissertations are a successful walk through a minefield -- summarizing
> > them
> > > is not. - Roy Fielding
>
> > --
>
> > You received this message because you are subscribed to the Google Groups
> > "nodejs" group.
> > To post to this group, send email to nod...@googlegroups.com.
> > To unsubscribe from this group, send email to
> > nodejs+un...@googlegroups.com<nodejs%2Bunsu...@googlegroups.com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/nodejs?hl=.
>
> --

> Rakesh Pai
> Mumbai, India.
> rakesh....@gmail.comhttp://piecesofrakesh.blogspot.com/

[Ripter]

Personally I've always like John Resig Micro template
http://ejohn.org/blog/javascript-micro-templating/
You just use normal javascript. No special syntax and you get the full
power javascript at your disposal.

On Nov 23, 6:48 am, Onne <o.gor...@gmail.com> wrote:
> My personal preference is:

>  http://json-template.googlecode.com/svn/trunk/doc/Introducing-JSON-Te...

[Hagen]

My personal preference is:
 http://json-template.googlecode.com/svn/trunk/doc/Introducing-JSON-Template.html

Interesting as well. How does JSON-Template deal with {} in the template? I am asking because I code generate Javascript and obviously have lots of {} in the templates. 

[Karl Guertin]

On Mon, Nov 23, 2009 at 6:48 AM, Onne <o.go...@gmail.com> wrote:
> My personal preference is:
>  http://json-template.googlecode.com/svn/trunk/doc/Introducing-JSON-Template.html
>
> which you can just use today, since it has zero non-js dependencies.

That's also my preferred pure js templating engine (python's Genshi is
my favorite). My complaint with jsontemplate is that I really believe
named sections and a .call-section need to be a part of the engine. If
you look at his explanation of why no other features are necessary
[1], and particularly at the code attached to "reusing the inside",
he's implementing template re-use by writing a custom formatter. This
is not only a considerable amount of code for a simple concept (markup
reuse), but it also requires every template you want to reuse to be
routed through the formatters. You can have each one register itself
to keep yourself from having to edit more_formatters every time, but I
still think it'd be a mess to maintain.

[1] http://json-template.googlecode.com/hg/doc/On-Design-Minimalism.html

I also dislike the use of spaces in directive names (e.g. {.repeated
section XXX}) so I replace the spaces with - (e.g. {.repeated-section
XXX}). A minor complaint, and an easy fix since the parsers are so
simple.

[Karl Guertin]

On Mon, Nov 23, 2009 at 7:24 AM, Hagen <six...@gmail.com> wrote:
> Interesting as well. How does JSON-Template deal with {} in the template? I
> am asking because I code generate Javascript and obviously have lots of {}
> in the templates.

You redefine the {} meta characters. It's easy to swap them to (say)
<<>> or any other even length string you want.

[Jérémy Lal]

My favorite template language is TBS (tinybutstrong.com), which separates
very well view from controller.
See for yourself...

> --
>
> You received this message because you are subscribed to the Google Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com.

> To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.

[Joshaven Potter]

I don't believe this will work.  It looks great with this example but you cannot have multiple properties of an object named alike wheras you can have multiple elements named alike.

How would you represent:

<!-- html "template" -->
<div id="example">
 <h2>Title</h2>

 <p>Something here</p>

 <a href='http://google.com'>Search something</a>

 <p>Yet another paragraph... herein lies the issue</p>

 <p class="foo"></p>
</div>

You cannot make the 'p' property an Array because there will be cases where elements need to be between the elements of the Array.  You could require the developer to make elements unique through providing a class or id but I would not want my template language to dictate my layout so I would strongly oppose that option.

Layout could be expressed in an Array because elements of the Array do not have to be unique but syntax would not be as nice.

I suggest a layout language that is not JavaScript but can be easily parsed and can contain JavaScript.  I often use HAML & ERB for ruby and am the happiest with HAML.  Tim has done some work with Haml like templating... check out his project:  http://github.com/creationix/jquery-haml

--

You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/nodejs?hl=.

--
Sincerely,
Joshaven Potter

"No man making a profession of faith ought to sin, nor one possessed of love to hate his brother. For He that said, “Thou shalt love the Lord thy God,”  said also, “and thy neighbor as thyself.”  Those that profess themselves to be Christ’s are known not only by what they say, but by what they practice. “For the tree is known by its fruit.”" -- Ignatius

[Jeff Smick]

libxml2 does have an HTML mode (see Ruby's Nokogiri). While libxmljs
does not support the HTML mode, libxml provides it.

[Tim Caswell]

Thanks for mentioning my project.  I've actually split the project into it's client-side and server-side parts.

The parser that parses actual haml server side is http://github.com/creationix/haml-js, the one you linked to is a jquery plugin that allows for client side templates that actually dom-build in the browser.

As has already been said in this thread, sometimes you want something more flexible than properly formatted xml.  haml-js is great for building xhtml structure and is a much better syntax than pure xml.

If you need something more freeform than another templating language would work better.  It all depends on your need.

Also I agree that designing a simple language and then writing a parser is javascript is a good idea sometimes.  The tradeoff is your language will take more to learn, but hopefully be easier to use in the long term.  JavaScript wasn't designed to be a document language, html was meant for that in the browser.  But on the other hand, we all know Javascript already, but I bet few of you know my TopCloud language I made up.

[Isaac Z. Schlueter]

Wow, this sure is an interesting thread. A lot of great ideas here.

Regarding the earlier suggestion of putting a DOM parser in Nodejs: I
think that's not a good idea. It would be best to build this kind of
parser as an extension (or simply a JS library) and provide it as a
node add-on that people could either use or ignore. I personally
favor having lots of choice over having to settle on a definition of
"ideal", and it would be a shame to burden the nodejs core with
something that one might never use.

The real benefit of choices is that we don't have to agree, or come up
with specs and votes and such. Just implement it, tell everybody
about it, and if they like it, they'll use it. If not, well, you've
probably learned something in the process, and you've created the
program YOU wanted to use!

--i

On Nov 23, 8:52 am, Tim Caswell <creatio...@gmail.com> wrote:
> Thanks for mentioning my project.  I've actually split the project into it's client-side and server-side parts.
>

> The parser that parses actual haml server side ishttp://github.com/creationix/haml-js, the one you linked to is a jquery plugin that allows for client side templates that actually dom-build in the browser.

>
> As has already been said in this thread, sometimes you want something more flexible than properly formatted xml.  haml-js is great for building xhtml structure and is a much better syntax than pure xml.
>
> If you need something more freeform than another templating language would work better.  It all depends on your need.
>
> Also I agree that designing a simple language and then writing a parser is javascript is a good idea sometimes.  The tradeoff is your language will take more to learn, but hopefully be easier to use in the long term.  JavaScript wasn't designed to be a document language, html was meant for that in the browser.  But on the other hand, we all know Javascript already, but I bet few of you know my TopCloud language I made up.
>
> On Nov 23, 2009, at 10:33 AM, Joshaven Potter wrote:
>
> > I don't believe this will work.  It looks great with this example but you cannot have multiple properties of an object named alike wheras you can have multiple elements named alike.
>
> > How would you represent:
>
> > <!-- html "template" -->
> > <div id="example">
> >  <h2>Title</h2>
>
> >  <p>Something here</p>
> >  <a href='http://google.com'>Search something</a>
> >  <p>Yet another paragraph... herein lies the issue</p>
>
> >  <p class="foo"></p>
> > </div>
>
> > You cannot make the 'p' property an Array because there will be cases where elements need to be between the elements of the Array.  You could require the developer to make elements unique through providing a class or id but I would not want my template language to dictate my layout so I would strongly oppose that option.
>
> > Layout could be expressed in an Array because elements of the Array do not have to be unique but syntax would not be as nice.
>
> > I suggest a layout language that is not JavaScript but can be easily parsed and can contain JavaScript.  I often use HAML & ERB for ruby and am the happiest with HAML.  Tim has done some work with Haml like templating... check out his project:  http://github.com/creationix/jquery-haml
>

> > For more options, visit this group athttp://groups.google.com/group/nodejs?hl=.

[Joshaven Potter]

I agree with Isaac!

For more options, visit this group at http://groups.google.com/group/nodejs?hl=.

[Ed Spencer]

I'll throw Jaml into the ring too.  Seems like tying to one particular implementation would be very limiting, especially given the infancy of this field.  The approach Rails takes to allow any installed templating library to be used is a great one - it looks a bit like this:

someTemplate.html.erb <= HTML rendered using the ERB library
anotherTpl.html.haml <= HTML rendered using the Haml library
rssFeed.xml.builder <= XML rendered by Builder

Having a common interface to register and render templates would allow the above to happen easily.  In implementing Jaml, the only functions I needed were register and render, looking a bit like:

MyLib.register('templateName', ... template markup of some kind ...)
output = MyLib.render('templateName', {data: 'value'});

Something like this would allow future templating libraries to be dropped in easily, and for application frameworks to support all libraries consistently.

http://edspencer.github.com/jaml/ has examples of how I have that working with Jaml...

Edward Spencer
Director, Dominé ltd

ExtJS and Ruby on Rails consulting
Tel: 01212 883399
Mob: 07977 922858
email: edw...@domine.co.uk

[Hagen]

Regarding the earlier suggestion of putting a DOM parser in Nodejs: I
think that's not a good idea.  It would be best to build this kind of
parser as an extension (or simply a JS library) and provide it as a
node add-on that people could either use or ignore.  I personally
favor having lots of choice over having to settle on a definition of
"ideal", and it would be a shame to burden the nodejs core with
something that one might never use.

I always meant the DOM parser to be a module. And yes, you should be allowed to ignore it. But I also think that a HTML parser should be as closely related to the browers' as possible. That's why I suggested that in the first place. Parsing HTML is far from trivial!

I guess I am in a unique position as my primary template TARGET is Javascript, not HTML. Currently, I am using a custom engine based on http://ejohn.org/blog/javascript-micro-templating/ (which is unsuitable as presented by John because it's killing whitespace)

However, when target and template use the same language, it can get very confusing when a certain code is actually executed (as part of the template or when the generated code is executed), at some points I even have triples (javascript generating javascript generating javascript). (And yes, it does make sense, when you see the architecture)

Anybody have pointers to people doing something like this and how to solve the issue of making the different execution times more clear?

[Tim Caswell]

I'm not sure what can be done for the "triples", but for the simple case where there is one level of generation, the best thing I can think of would be to use a text-based template engine like John's, but get a good editor with easily extensible highlighting engines and have the javascript code that is just template highlighted normally, and maybe the javascript that is to be executed have a different background color.  That way you could see the difference easily.  If you're working entirely command line, maybe write a quick script that parses a output file and highlights code sections in red.  

Usage:

node mygenerator.js | highlight

Then you could see the output, and for the case of "triples" you could see the intermediate output clearly.

Other than colors, I'm at a loss of what to do, the two languages are the same, so they'll have similar patterns.

[tjholowaychuk]

check out "Mojo" on github

[Simon Willison]

You wouldn't know it from the name, but libxml2 actually includes an
excellent HTML parser. I've used it extensively from Python via the
lxml library which even includes the ability to run XPath and CSS
selector expressions against the HTML DOM created by libxml2.

Cheers,

Simon

[Marak Squires]

Why not just use Mustache?

http://github.com/janl/mustache.js

[rektide]

I'm waiting for Env-JS to be able to run Dojox.DTL, at which point
I'll begin to care about how to integrate env-js and node.js. DTL is
the Dojo port of Django, which is good enough for me.

Alternatively, I might try to integrate JavascriptMVC.

[Flinn Mueller]

It seems node can be pretty agnostic about what template language you choose to use.  I think it's valid to ask what parsing libraries node might support, etc. but I'm not sure the business of a template language is node's concern.  To me node seems less like Rails and more like Rack or Sinatra if we're comparing it to the Ruby world.

[weepy]

It strikes me that we *need* something like ERB (Resig's micro
template looks very similar)

<%= %> and <% %>

It's super simple, super flexible, can handle all output types (not
just html), and it's also fast => probably the reason that nearly
every web framework uses it.

I'd vote for something like this as a vanilla implementation and then
we can try out more involved/completed alternatives.

As for alternatives, I've used HAML alot and it's pretty cool, but
it's another layer of abstraction. The HTML only template suggestion
cited at the start sounded interesting, but I imagine you'd have alot
of extra classes and markup, so that it was easy to select the correct
bits.

I've also tried {{mustache}} (http://github.com/defunkt/mustache),
which is quite interesting - here's some examples converted to
javascript:

--- presenting class ---
...
function name() {
return "Chris"
}

function value() {
return 10*1000
}
....

--- template ---
Hello {{name}}
You have just won ${{value}}!


--- output ---
Hello Chris
You have just won $10000!


It can also handle enumerables and booleans

--- presenter
function repo() {
return ["jonah","weepy"].map(function(x) {
return {name:x}
})
}

--- template
{{#repo}}
<b>{{name}}</b>
{{/repo}}

--- output

<b>jonah</b>
<b>weepy</b>

[weepy]

actually looks like someones already implemented a mustache.js

http://github.com/janl/mustache.js

On Nov 24, 6:18 am, tjholowaychuk <tjholoway...@gmail.com> wrote:

[Howardr]

I have always liked Erb in rails. I did a search on github and this
group and there was no equivalent of it in javascript. I threw
something together last night. I like something like this better than
a DOM engine because sometimes you are not returning html/xml. There
are still issues with this because for eval'ing you get global
variables and stuff, but it's a start.

http://gist.github.com/245851

Download:
ejs.js
example.js
example.html.js

Run:
node example.js

[Simon Rozet]

On Tue, Dec 1, 2009 at 12:12 AM, Howardr <how...@gmail.com> wrote:
> I have always liked Erb in rails.  I did a search on github and this
> group and there was no equivalent of it in javascript.  I threw
> something together last night.  I like something like this better than
> a DOM engine because sometimes you are not returning html/xml.  There
> are still issues with this because for eval'ing you get global
> variables and stuff, but it's a start.
>
> http://gist.github.com/245851
>
> Download:
> ejs.js
> example.js
> example.html.js
>
> Run:
> node example.js

http://ejohn.org/blog/javascript-micro-templating/



--
Simon Rozet <si...@rozet.name> http://atonie.org

[Howardr]

Thanks Simon. I remember reading that post a while ago. I wish I
would have remembered this before I hacked away.

On Nov 30, 6:42 pm, Simon Rozet <si...@rozet.name> wrote:

[Erin Carter]

mustache.js (http://github.com/janl/mustache.js) has a lot of
potential merely due to how simple the usage is. It's a pure JS port
of http://github.com/defunkt/mustache. Haven't used it before but
setting up a prototype may be worth a couple minutes and/or beers.

Guess I'll go find out.

-Erin

On Nov 23, 8:07 am, Simon Willison <si...@simonwillison.net> wrote:

[George Moschovitis]

> 1. the template is pure HTML no special markers or template syntax

This is nice, but restricts the template engine to html/xml files
only.
JSON-template might be a better alternative...

-g.

[Andrew Gwozdziewycz]

I started working on a port of Tornado web's template language. I
didn't get too far before getting interrupted, but I do plan on
finishing it.

> --
>
> You received this message because you are subscribed to the Google Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com.
> To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.

> For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
>
>
>



--
http://www.apgwoz.com

[weepy]

How does Tornado's template system differ from ERB (other than the
delimeters)

J

[Irakli Gozalishvili]

In case you're interested, there is commonjs compliant package with json-template. Fully js and really simple.it has python version as well, so templates are cross-language.

http://github.com/andychu/json-template

--
Irakli Gozalishvili
Web: http://rfobic.wordpress.com/
Phone: +31 614 205275
Address: Taksteeg 3 - 4, 1012PB Amsterdam, Netherlands

[Sean]

I've got Google's Closure Templates working inside NodeJS, if anyone
is interested in that option:

http://www.dashdashverbose.com/2009/11/closure-templates-and-nodejs-server.html

-Sean

On Nov 20, 10:43 pm, Tero Piirainen <tipii...@gmail.com> wrote:
> First: I'm really impressed with nodejs. Thank you guys! This will
> change the world. Now that we have a fresh start for an ideal server
> side framework I'm proposing here a syntax for an ideal template
> language. Here is an example
>
> <!-- html "template" -->
> <div id="example">
>   <h2>Title</h2>
>
>   <p>Something here</p>
>
>   <p class="foo"></p>
>
> </div>
>
> And here is the JS that will make dynamic changes to the template
>
> // the JavaScript
> {
>  '#example': {
>     h2: 'My updated title',
>     p: 'My content',
>     '.foo': gerSomeDataByScripting()
>  }
>
> }
>
> So what is so special about this
>

> 1. the template is pure HTML no special markers or template syntax

[mvalente]

First let me state that any serverside templating is a crime
against kittens, another
one dies everytime templating is done serverside.
And another one dies if the templating system messes with regular
HTML with
things like $var and {:foo} and what not....

That being said, I agree with you with the *pure* HTML templating.
Check out:

http://mvalente.eu/2009/11/25/requirements-for-a-modern-web-development-framework/
http://beebole.com/pure/
http://wiki.github.com/raid-ox/chain.js/

-- MV

[shaner]

I've used the trimpath templating engine both in the browser and via
rhino (the mozilla java javascript engine).
http://code.google.com/p/trimpath/wiki/JavaScriptTemplates
It also works with Node.

It uses pretty vanilla templating syntax like:
{for product in products}
buy the ${product.name} for ${product.price}
{/for}

I really like this library and I like that it's reasonable performant
since it caches parsed templates as javascript code (very similar to
PHP's Smarty language).
--Shane

[rektide]

On Nov 24, 2:10 am, weepy <jonah...@gmail.com> wrote:
> It strikes me that we *need* something like ERB  (Resig's micro
> template looks very similar)
>
> <%= %> and <% %>

[snip]

http://ejohn.org/blog/javascript-micro-templating/

That only took 35 lines. I wrote that myself once, albiet not quite
in 35 lines. I need to resurrect it actually, wherever it lives, as
it doesnt use with(obj).

[Jed Schmidt]

If it helps, I ported Resig's approach into a node module a while
back, and added the ability to use multiple contexts and load
templates from a directory:

http://github.com/jed/tmpl-node

Jed Schmidt

[Howard Rauscher]

Haha.  I also copied Resig's approach after a suggestion yesterday (http://github.com/howardr/ejs).  Although I am thinking of ditching mine already and using Jed's because of the extra features he has included.

--Howard

[Andrew Gwozdziewycz]

On Tue, Dec 1, 2009 at 11:44 AM, weepy <jona...@gmail.com> wrote:
> How does Tornado's template system differ from ERB (other than the
> delimeters)

I don't know erb so I'm afraid I can't answer that. My guess is that
there probably isn't much different other than syntax, and like you
said delimiters. Maybe it would be a good idea to not add to the list
of potential choices for template languages and adopt another....

[weepy]

>> http://github.com/jed/tmpl-node

Looks awesome Jed.

[Erik Garrison]

Agreed.

On Wed, Dec 2, 2009 at 11:51 AM, weepy <jona...@gmail.com> wrote:
>>> http://github.com/jed/tmpl-node
>
> Looks awesome Jed.
>

[Olivier Percebois-Garve]

I agree so much to this and to your blog post. 

Against my will,  have been doing heavy smarty development a few years ago, and that was a kittens bloodbath on a daily basis.

Templates with logic in it are not a little nifty thing, they are an extra layer on the stack. They are  frameworks, even if they dont pretend to, and they constraint to learn a new meta-language, even if they pretend it to be sort of "natural". Also they are the best way to divide a large community into dozens of small sectarian groups, unable to share code with eachothers.

Being a smarty developer is very frustrating and boring.

There is no need for a template engine in order to use templates.

Putting most of the logic in the presentation layer is just as wrong as putting most of the presentation into the logic layer.

I hope something will be done to save kittens.

Olivier

--

You received this message because you are subscribed to the Google Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com.
To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.

[Jérémy Lal]

Even if it does not really save kittens,
that's the reason why i'm currently using TBS (www.tinybutstrong.com)
which keeps the html templates readable and bring some clever ideas about
templates :)
Please have a look at the examples on the web site, or consider this :

<table>
<tr>
<td>[myblock.name;block=tr]</td>
<td>[myblock.text]</td>
</tr>
</table>

merging rows of a table is as simple as calling
mergeBlock('myblock', [{name:'n1', text:'text1'}, {name:'n2', text:'text2'}])

Display is controlled via 'magnet' and 'bmagnet' params.
Some logic is available :

<div><p>[myField;if [val]='toto';then 'Hello';else '']</p></div>

and so on... The manual is complete and examples are provided.
TBS is a php template engine, but portable in other languages, since it really
is just string manipulations.

Jérémy.

> <mailto:nod...@googlegroups.com>.

> To unsubscribe from this group, send email to
> nodejs+un...@googlegroups.com

> <mailto:nodejs%2Bunsu...@googlegroups.com>.

[Moritz Peters]

That looks really horrible. Especially the second part.

> > On Tue, Dec 1, 2009 at 7:40 PM, mvalente <mfvale...@gmail.com
> > <mailto:mfvale...@gmail.com>> wrote:
>
> >       First let me state that any serverside templating is a crime
> >     against kittens, another
> >      one dies everytime templating is done serverside.
> >       And another one dies if the templating system messes with regular
> >     HTML with
> >      things like $var and {:foo} and what not....
>
> >       That being said, I agree with you with the *pure* HTML templating.
> >     Check out:
>

> >      http://mvalente.eu/2009/11/25/requirements-for-a-modern-web-developme...

>  signature.asc
> < 1 KBAnzeigenHerunterladen

[Micheil Smith]

I'm with a few of the others who would prefer something similar to
ERB, excepting, more javascript and less ruby.

Maybe dub it EJS, Embedded JavaScript.


- Micheil

[Jérémy Lal]

I just want to present two objections :
- the template (in cases where one uses html) must be merged to be viewable on a web browser,
on most current templating systems, the unmerged template is simply unviewable.
- the template is bound to the language (js here). If someone needs to use
those templates with another language as controller, it's painful to port them.

tbs is not a really good idea as it is, i agree. It went quite wrong nowadays.
Still :
- there is something nice with defining in the view which parts to repeat when merging "tables".
That way, the controller does not have to know where the data to be merged should be in the
template.
- blocks of data to repeat don't need a beginblock - endblock, so it's still readable before merge

I won't troll any more :)

Jérémy.

[Olivier Percebois-Garve]

I'm not less a troll than you, and I love healthy debate.

I'm not sure what you mean by "merge" but for those last 2 points it should be doable. If it needs to be done often, then it can be abstracted to some kind of "helper" function.

templates should be pure HTML, and portable everywhere.

[Siegmund Führinger]

i guess this whole debate shows, that there isn't a single template
language, that suits everyone.
and that is ok.
but what is confusing me is why this debate takes place on the node.js
mailinglist. is anyone suggesting, that a template engine is included
in node.js? (i hope not).

cheers,
sifu

[Micheil Smith]

To say that they should be "portable everywhere" is very honourable as a
suggestion, but more then likely very impractical to do.

Just my $0.02 worth on that.

- Micheil.

> <mailto:holi...@gmail.com>> wrote:
> >>
> >>> Even if it does not really save kittens,
> >>> that's the reason why i'm currently using TBS

> (www.tinybutstrong.com <http://www.tinybutstrong.com>)

> >>> which keeps the html templates readable and bring some clever
> ideas about
> >>> templates :)
> >>> Please have a look at the examples on the web site, or
> consider this :
> >>>
> >>> <table>
> >>> <tr>

> >>> <td>[myblock.name <http://myblock.name>;block=tr]</td>

> >>>> <mailto:mfvale...@gmail.com <mailto:mfvale...@gmail.com>>> wrote:
> >>>>
> >>>> First let me state that any serverside templating is a
> crime
> >>>> against kittens, another
> >>>> one dies everytime templating is done serverside.
> >>>> And another one dies if the templating system messes
> with regular
> >>>> HTML with
> >>>> things like $var and {:foo} and what not....
> >>>>
> >>>> That being said, I agree with you with the *pure* HTML
> templating.
> >>>> Check out:
> >>>>
> >>>>
> http://mvalente.eu/2009/11/25/requirements-for-a-modern-web-developme...
> >>>> http://beebole.com/pure/
> >>>> http://wiki.github.com/raid-ox/chain.js/
> >>>>
> >>>> -- MV
> >>>>
> >>>> On Nov 21, 6:43 am, Tero Piirainen <tipii...@gmail.com
> <mailto:tipii...@gmail.com>

> >>>> <mailto:tipii...@gmail.com <mailto:tipii...@gmail.com>>>

> >>>> <mailto:nod...@googlegroups.com

> <mailto:nod...@googlegroups.com>>.
> >>>> To unsubscribe from this group, send email to
> >>>> nodejs+un...@googlegroups.com
> <mailto:nodejs%2Bunsu...@googlegroups.com>

> >>>> <mailto:nodejs%2Bunsu...@googlegroups.com
> <mailto:nodejs%252Buns...@googlegroups.com>>.

> >>>> For more options, visit this group at
> >>>> http://groups.google.com/group/nodejs?hl=en.
> >>>>
> >>>> --
> >>>>
> >>>> You received this message because you are subscribed to the
> Google
> >>>> Groups "nodejs" group.
> >>>> To post to this group, send email to nod...@googlegroups.com
> <mailto:nod...@googlegroups.com>.
> >>>> To unsubscribe from this group, send email to
> >>>> nodejs+un...@googlegroups.com
> <mailto:nodejs%2Bunsu...@googlegroups.com>.
> >>>> For more options, visit this group at
> >>>> http://groups.google.com/group/nodejs?hl=en.
> >>>>
> >>>

> >>> signature.asc
> >>> < 1 KBAnzeigenHerunterladen
> >>>
> >>
> >> --
> >>
> >> You received this message because you are subscribed to the
> Google Groups "nodejs" group.

[Micheil Smith]

The discussion is relevant however, as it ties in with the discussion on
an MVC framework for Node.js (see the other threads.)

- Micheil.

[weepy]

EJS is generally viewable, e.g.


<p>Title is <%= myvar.title %></p>

<% myvar.each(function(x) %>
<p>Output is <%= x.output %></p>
<% } %>



Looks like the following in Firefox

Title is <%= myvar.title %>
<% myvar.each(function(x) %>

Output is <%= x.output %>
<% } %>


Given how often we use anonymous functions, It might be nice to find a
shortcut, eg:

<% myvar.each( {{ Output is = <% a.output %> }} ) %>

> >> For more options, visit this group athttp://groups.google.com/group/nodejs?hl=en.

>
> > --
>
> > You received this message because you are subscribed to the Google Groups "nodejs" group.
> > To post to this group, send email to nod...@googlegroups.com.
> > To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/nodejs?hl=en.
>
>
>
>  signature.asc

> < 1KViewDownload

[mvalente]

Horrible being kind. Its ghastly.

Me and a friend worked on this during this years Codebits (
http://codebits.eu/ ). Or rather
he (Rui Lopes) worked and I stood on the side playing enterprise
systems architect :)

Rui already has a working prototype and hopefully he will unveil
it the coming days.

But here is an overview/example:

- I got to http://foo.com/ the Accept header is HTML (its a
browser request), the server
returns the index.html file (or the index_html object)
- assume that this HTML is basically:
<div id="header" class="html">
<div id="content" class="html>
<div id="footer" class="html">
- the clientside templating system makes requests for header.html,
content.html and footer.html, filling in the DIVs contents
- assume that content.html is:
<p> Hello <span id="name"> </p>
<p> The time is <span id="servertime"> </p>
- the clientside templating system will then make a request to
http://foo.com/content with Accept header JSON, receives a
JSON hash, retrieves the values for keys "name" and
"servertime"
and fills in the SPAN elements
- the browser now goes to http://foo.com/bar/
- since there's no index.html at that location, the templating
system
goes a level up in the hierarchy (filesystem or object) and
fetches
http://foo.com/ and gets back the already mentioned index.html
- once again it requests header, content and footer. Since
header.html
and footer.html dont exist, they are inherited from the level
above.
Since the content.html file (object) exists at /bar, that
local content.html
is used to fill in that slot.
- the clientside templating system then makes a request to
http://foo.com/bar/
with Accept JSON and receives back a JSON hash with keys and
values
with which to fill in the html elements identified by "id"
attribute.

Its working nice, Rui is ironing some sticky points, but thats how
it works. It
basically works in a way similar to Zope's DTML templates and
inheritance.

-- MV




On Dec 3, 12:53 pm, Moritz Peters <maritz.pet...@googlemail.com>
wrote:

[Mic (BeeBole)]

Hi Tero,
The unobtrusive syntax you are referring to is exactly the one of PURE
a JS templating library: http://beebole.com/pure
There is a thread about it here:
http://groups.google.com/group/nodejs/browse_thread/thread/9a248d871e240e7a/c4b79598633e9c72
cheers,

On Nov 21, 7:43 am, Tero Piirainen <tipii...@gmail.com> wrote:
> First: I'm really impressed with nodejs. Thank you guys! This will
> change the world. Now that we have a fresh start for an ideal server
> side framework I'm proposing here a syntax for an idealtemplate
> language. Here is an example
>
> <!-- html "template" -->
> <div id="example">
>   <h2>Title</h2>
>
>   <p>Something here</p>
>
>   <p class="foo"></p>
>
> </div>
>
> And here is the JS that will make dynamic changes to thetemplate
>
> // the JavaScript
> {
>  '#example': {
>     h2: 'My updated title',
>     p: 'My content',
>     '.foo': gerSomeDataByScripting()
>  }
>
> }
>
> So what is so special about this
>

> 1. thetemplateis pure HTML no special markers ortemplatesyntax

[JoeS]

I'm working on my own templating engine that is focused on main
features: templates function with or without javascript enabled on the
client, and, at the same time, enable a rich experience for the
majority of users who do have javascript enabled - so that many
updates do happen client side only.

For example, an 'add comment to blog' feature could either a) update
the page inline with ajax or b) reload the page from the server.
Either way we want it to produce an identical result (minus any
javascript based animation effects). What I've come up with so far is
the concept of data binding. The template language is heavily inspired
by json-template, but links all the template language commands to a
javascript binding object. This binding acts as a layer between the
controller code and the view, allowing the view to be dynamically
updated (inline for client side, completely rendered for server side).
For example:

//controller action that sends its result back to a framework level
event handler
//this case is called on form submit for the 'add comment' form
data = ...some data returned from a database callback query...;
page_binding = templates.template_name.bind(data)
new_comment = ...load some data from the form, make a new Comment
object...
if (new_data.is_valid())
page_binding.comments.push(new_comment) //add the new comment to
the page
else
page_binding.new_comment.errors = new_data.validation_errors() //
show the errors on the page
return page_binding

//framework level - processes the result of the above controller
action:
//server side:
http_response.send(page_binding.render()) //full page render, send
back html
//client side:
page_binding.update() //DOM manipulation with possible animations and
such

The key point is that the controller is identical server side and
client side. The framework is just a thin layer that provides a
uniform base for the server/client side - so that controllers don't
have to care where they're running. The page binding 'render' would
render a full template, whereas the 'update' function would be able to
render just the 'comment' sub-template, make a dom node for it, and
append it to the right parent in the DOM.

At any rate, I've got a decent portion of this done and working, and
will post once I'm finished. Thoughts/suggestions welcome.

[tfreitas]

I like the idea of PURE (http://beebole.com/pure/),
the concept of separation of data into JSON and the template to render
into HTML.
Obviously "PURE" need a "selector" on the server side, something like
the DOM / CSS in browser

[816...@gmail.com]

Looks pretty, but in my opinion template engine should completely
separate template and logic, for example it should provide the
possibility to change template for another without any changes in logic

[Jérémy Lal]

i second that !
it should also support plain text files the same way (eg csv files),
so should not rely upon an xml or html parser...

i might have time next month to experiment my own template engine, hopefully...

[tjholowaychuk]

yeah check out libxmljs, I am using it with ElementCollection in
Express http://github.com/visionmedia/express
for mining sites etc, basically ElementCollection is server-side
jQuery, and will be abstracted into its own library
once my nodejs package manager 'kiwi' is finished.

On Nov 23 2009, 6:07 am, Simon Willison <si...@simonwillison.net>

[Andy]

On Jan 15, 7:16 am, "Jérémy Lal" <holi...@gmail.com> wrote:
> i second that !
> it should also support plain text files the same way (eg csv files),
> so should not rely upon an xml or html parser...

If that's your requirement, then JSON Template should fit well:
http://code.google.com/p/json-template/

PURE is HTML + JSON = HTML

JSON Template is template + JSON = arbitrary text.

That is, it doesn't know anything HTML. I've used it for generating
code from an AST, batch files, etc.

Andy

[andrei]

I want to know if Webkit integration makes able using its canvas for
image manipulation?

On Nov 23 2009, 1:15 pm, Hagen <six...@gmail.com> wrote:
> Hpricot is cool. The only reason I suggested webkit's is the existing
> integration of that parser and v8 somewhere available in chrome.
>
> Otoh, having a DOM would make integrating server-side and client-side code
> even more trivial. E.g. an implementation of the template engine spawning
> this thread could reuse jQuery code for selecting the correct node.
>
>
>
> On Mon, Nov 23, 2009 at 11:09 AM, Ryan Dahl <coldredle...@gmail.com> wrote:

> > On Mon, Nov 23, 2009 at 11:04 AM, Hagen <six...@gmail.com> wrote:
> > >> I will be putting Jeff Smick's binding of libxml2 into the
> > >> distribution at some point.
>
> > > Please correct me if I am wrong, but libxml2 does not have an HTML mode.
> > > Having libxml2 is cool and all, but having a true HTML parser is a whole
> > > different beast. Believe me, I tried implementing a web crawler, parsing
> > > HTML is a royal pain if you don't have access to a browser's parser.
>

> > Sounds like a reasonable feature to have. Maybe using _why's parser
> > from Hpricot is better / less entangled than webkit.

>
> > --
>
> > You received this message because you are subscribed to the Google Groups
> > "nodejs" group.
> > To post to this group, send email to nod...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > nodejs+un...@googlegroups.com<nodejs%2Bunsu...@googlegroups.com>

> > .
> > For more options, visit this group at

> >http://groups.google.com/group/nodejs?hl=.
>
> --
> Dissertations are a successful walk through a minefield -- summarizing them
> is not. - Roy Fielding

[Rasmus Andersson]

I like Mako <http://www.makotemplates.org/> -- simple, fast, syntax
looks like other template languages (meaning ppl don't have to learn a
new template language) and is text-based (no silly HTML or alike)

Example (from the aforementioned URL):

<%inherit file="base.html"/>
<%
rows = [[v for v in range(0,10)] for row in range(0,10)]
%>
<table>
% for row in rows:
${makerow(row)}
% endfor
</table>

<%def name="makerow(row)">
<tr>
% for name in row:
<td>${name}</td>\
% endfor
</tr>
</%def>

...

Would be neat to have that in node/javacsript, although I've
personally stopped believing in server-side templating (since web
browsers do this now days and it's called HTML ;). However still nice
for things like CSV, Atom, RSS, etc.

> --
> You received this message because you are subscribed to the Google Groups "nodejs" group.
> To post to this group, send email to nod...@googlegroups.com.

> To unsubscribe from this group, send email to nodejs+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/nodejs?hl=en.
>
>
>
>

--
Rasmus Andersson

[Rasmus Andersson]

If anyone is interested, I've implemented a parser/compiler for a
<%-based template language here http://github.com/rsms/elua (and a
ruby-targeted version here
http://github.com/rsms/rhp/blob/master/ext/rhp/module.c). It's MIT so
if any code looks yummy pls use it (for building a node version :).

--
Rasmus Andersson

[Owen Williams]

It seems to me that everyone is going to have a different "favorite" templating language, so I wonder if having a "standard" one in Node is a good idea.

Once we have a package manager working, I'm sure it will be very easy to pick one of a number of templating systems that folks will package for node.

cheers
O

[Miguel Cavaco Coquet]

Completely agreed.

[Rasmus Andersson]

On Mon, Jan 18, 2010 at 19:46, Owen Williams <owe...@gmail.com> wrote:
>
> It seems to me that everyone is going to have a different "favorite" templating language, so I wonder if having a "standard" one in Node is a good idea.
>
> Once we have a package manager working, I'm sure it will be very easy to pick one of a number of templating systems that folks will package for node.

+1

Naturally there will exist many different templating modules. Not
something usually found in a standard library either.

[Iván -DrSlump- Montes]

Everyone has its favorite templating syntax or engine, however there is room for inter-operation and code reuse. Template configuration and runtime "context" management are components needed by any templating engine, which could certainly be "standards", perhaps not in Node itself but as an independant module used by all the different engines.

The template configuration I refer to is basically an interface to set the variables, clone the "template", configure paths where template files are to be searched for ...

The Runtime Context just holds the template data set in the configuration phase and  offers (configurable) methods for escaping that data.

Sharing this common components among template engines would allow to easily migrate from one to another and even change them for different types of responses (html, email, text...)

/imv

[George Moschovitis]

You could also consider this (available as a CommonJS template):

http://github.com/gmosx/normal-template

It replaces the 'cursor' model of JSON-Template with (a subset of)
XPath and provides an optional meta-templating mechanism.

-g.

--
http://www.gmosx.com/blog
http://www.appenginejs.org