Thanks for the thoughtful reply, Duncan. You had a lot of questions in
there, and I'll try to answer most of them. We, the developers at Wildfire
Interactive have discussed most of those concerns, and I think you and I
are on the same page.
One of the main goals of adding JS delimiter support is that we would be
able to keep the semantic significance of indentation. Hamlbars has
helpers, but block expressions such as 'each' cannot take nested haml
blocks. This may be an implementation detail with Hamlbars that could be
amended, but it's just not there yet, and we think it's an important
missing feature.
I like the implementation that you suggested whereby using a '^' character
disassociates the javascriptiness of other delimiters (such as {{ or {%) in
a similar fashion to that of the '%' character with open angle brackets.
Having said that, I'm not quite sure where that fits in the scheme of
things because I am not TOO familiar with ejs, but it looks so similar to
erb that I'm afraid people will be confused by the output, whereas some of
the other delimiters out there look javascripty by their very nature (curly
braces == javascript ?).
As far as humans having to parse through 3 different languages...keep in
mind that no one is obligated to use these delimiters, just as much as no
one is obligated to use the Textile or Markdown filters. This is just a
tool in the belt that could make writing JavaScript templates as easy as
writing haml/ruby templates.
If anyone else has any input, I think this may turn out to be an important
topic,...please chime in :-)
Cheers,
Bernie
On Sunday, April 22, 2012 10:10:49 AM UTC-7, Duncan Beevers wrote:
>
> There have been a number of approaches to help make it simpler to use
> haml for client-side templates. One popular implementation is hamlbars
> https://github.com/jamesotron/hamlbars which provides some helper
> methods, and my own academic experiments in extending haml in a
> similar fashion here: https://github.com/duncanbeevers/haml-ejs
>
> That said, many client-side templating languages use different or
> customizable delimiters, and support different subsets of javascript
> within the templates, from full-js-interpretation all the way down to
> only-top-level-properties-of-a-single-data-object, and extending haml
> to deal with all of these is pretty much guaranteed to only serve a
> subset of the needs programmers will have down the line.
>
> haml itself is already a member of the school of templating languages
> that provide access to the full functionality of the ruby interpreter
> within the template. Adding extra delimiters means a human looking
> over a templates needs to mentally parse two to three languages just
> to figure out what's going on.
>
> Is haml the way forward? Should it be re-plumbed to make adding custom
> delimiters part of its public API? Should it embrace generation of
> client-side templates and include first-class support for this new
> family of consumers?
>
> I don't know. So far, using haml for these purposes has been a mixed
> bag. The results have been great, but the friction on the way has not
> been pleasant.
>
> On Sat, Apr 21, 2012 at 12:40 PM, Bernie wrote:
> > Just want to make sure I don't use time that could be spent somewheret
> > else. Here's the idea:
> >
> > Many JS templating languages appear to use the "{{ some_content }}"
> > strategy for delimiting content, and Mustache and Handlebars appear to
> > be the most popular among those lang's.
> >
> > Since Haml appears to not have an easy way to add custom delimeters
> > (parsing occurs all the way in the parser.rb file), would it make
> > sense to add these "{{" delimeters directly to haml?
> >
> > The end result would be something like this:
> >
> > %table
> > %tbody
> > {{# each MyApp.MyArray
> > %tr
> > %td {{ someValue }}
> > %tfoot
> > %tr
> > %td Some footer content
> >
> > Thoughts, concerns?
>
>
--
You received this message because you are subscribed to the Google Groups
"Haml" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/haml/-/oIBA5Jqd1rcJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to [email protected].
For more options, visit this group at http://groups.google.com/group/haml?hl=en.
