I originally wanted to simply retarget haml so that it generated
javascript templates rather than invoking the Ruby interpreter. Just
as Hampton mentions, the canonical way to output a variable would be.
%span= username
In the current implementation, the result of compiling this would be
something like:
<span>duncan</span>
Retargeted, I imagined haml outputting something like this instead:
<span>{{username}}</span>
But I found that I still needed and wanted access to pieces of the
Ruby environment like configuration values, url-generation methods,
and markup-generating methods like link_to. Faced with the trade-off,
I elected to extend the semantics of haml to make it easy to generate
the kinds of simple expressions in wanted in my client-side templates
while continuing to express myself using the elegant style haml
brought to the Ruby in my templates.
Right now, in order to generate simple mustache conditional I have to
jump through a few hoops.
In an ideal world I'd write:
%p
{{#sunny}}
My kind of weather
But mustache ain't haml, so I have to close the block myself. However,
because of haml's indentation rules, I can't just write this:
%p
{{#sunny}}
My kind of weather
{{/sunny}}
So I have a couple of options. I can either write this:
%p
:text
{{#sunny}}
My kind of weather
{{/sunny}}
Or this:
%p
{{#sunny}}My kind of weather{{/sunny}}
I wanted haml's indentation awareness to make the loops and
conditionals in my templates feel like coffeescript, and like haml
itself, without having to give up (read, change or modify) the bits of
template I'd written that relied on Ruby.
As far as the specific sigils I introduced, I knew I wanted more
control over the generated output than I would get targeting mustache
which can do a number of different things when it encounters a sigil
like {{#, such as performing a conditional check, invoking a function,
or looping over a collection of values. Instead, I had
explicitly-specified output for the specific pieces of functionality I
wanted to allow the client-side template access to.
I never opened a pull request for this because I never believed it was
something that belonged in haml core. I feel the first approach was
likely to get bound up in painful compromises trying to effectively
translate Ruby to JavaScript/template dialect, and my approach changes
the semantics of haml in a backwards-incompatible way.
On Tue, Apr 24, 2012 at 4:05 PM, Hampton <[email protected]> wrote:
> I'd have to say that I don't clearly understand why we'd use this delimiter?
> It would
> break existing code... what if that appeared naturally in your Haml?
>
> The recommended way is either.
>
> .span #{myvar}
> .span= myvar
>
> I have no personal problem with {{_}}, but what does it have that is so much
> better than #{_} that
> would be useful for these purposes?
>
> Now, there is a bigger question being breached here, which is Haml's
> relationship to client-side
> scripts... I have to say I have mixed feelings on this topic in a general
> sense. Seems like Haml
> would be a bad fit... unless you used Haml to *generate* some JS that was
> the proper template
> you were looking for. But, structured, semantic html is something that is
> already implicit in well
> defined JS data structures... aka,
>
> {name: {first_name: "hampton", last_name: "catlin"}}
>
> can easily be converted to
>
> <div class="name"><div class="first">hampton</div>.... blah, blah i hate
> typing, but you get it
>
> I'm not sure how much advantage Haml gives in a data=>template
> transformation which is the
> primary usage of Moustache&co.
>
> Haml focuses on document layout and structure. Which does have some overlap,
> but not enough
> in my mind.
>
> I do have some thoughts recently on things I want to see get added to Haml,
> but I'd have to say this isn't
> one of them.
>
> -hampton.
>
> On Tue, Apr 24, 2012 at 3:53 PM, Bernie <[email protected]> wrote:
>>
>> Jordan, I'm not sure I understand...isn't that just the Ruby way to do the
>> same thing? How would that look on the client side?
>>
>> --
>> 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/-/h9M7fHBAFiUJ.
>>
>> 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.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Haml" group.
> 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.
--
You received this message because you are subscribed to the Google Groups
"Haml" group.
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.
