My personal opinion is that we shouldn't want our templating engine  
to be too smart. Special handling in certain instances such as you  
mention here is soooo tempting because it happens so often, but it  
violates the principle of least surprise. I expect

= <an expression>

to behave exactly the same way no matter what follows it. What would  
be surprising is if somewhere along the line that behavior changed on  
a case by case basis.

Just my $.02.



On Feb 10, 2007, at 5:37 PM, Jeff wrote:

>
> I needed ~ to make my textareas work.  Why would one ever want the
> unfiltered behavior for textarea and pre tags?  Why doesn't haml
> filter those tags automatically?  IMHO haml breaks those tags and I
> shouldn't have to use a filter to get the behavior I would expect.
>
> I think I should be able to say:
> = textarea :user, :profile
>
> and get the same result as is currently returned by
> ~ textarea :user, :profile
>
> The new methods may improve the haml source code, but from my
> perspective as a user, they don't improve ease of use or readiblity of
> my code.
>
> Thanks,
> -- Jeff
>
> On Feb 6, 3:30 am, Nathan Weizenbaum <[EMAIL PROTECTED]> wrote:
>> That's right, folks, Haml is deprecating one of its commands: the
>> (apparently little-known) "~". Once useful for allowing people to  
>> create
>> whitespace-sensitive blocks of text inline, and styliciously handling
>> <textarea> and <pre> tags, "~" is now more or less rendered redundant
>> with the introduction of filters
>> (http://groups.google.com/group/haml/browse_thread/thread/ 
>> 5ed706013a47...)
>> and a clever use of helper functions.
>>
>> "~" had two different functions. First, it could be used as an
>> alternative to "=" that would replace all newlines in
>> whitespace-sensitive tags such as <pre> and <textarea> with the HTML
>> characters for newlines, thus preserving both whitespace /and/ style.
>> This function can now be done literally with a function:
>> find_and_preserve. For example, what was once:
>>
>> ~ text_area :user, :profile
>>
>> becomes
>>
>> = find_and_preserve(text_area :user, :profile)
>>
>> There's also another, related helper function, just called  
>> "preserve",
>> that removes all newlines period, without regard for what tag is  
>> where.
>>
>> The second function was to precede a nested block of text, which  
>> would
>> ensure that all whitespace in that text was preserved. The idea of  
>> doing
>> stuff with nested blocks of text might sound a lot like filters to
>> you... and it does to us, too, which is why we're replacing that
>> function with an actual filter.  The "preserve" filter serves the  
>> same
>> purpose as the "~" on its own. For instance, what was
>>
>> %pre
>>   ~
>>     1
>>      2
>>       3
>>        4
>>
>> is now
>>
>> %pre
>>   :preserve
>>     1
>>      2
>>       3
>>        4
>>
>> The "~" command will still be around, although undocumented, as of  
>> the
>> next release of Haml (1.5). If you use it, Haml will spit out a  
>> warning,
>> but it will work. However, in the release after 1.5, it will be  
>> gone for
>> good, so update your views as soon as possible.
>>
>> You may be wondering why we're deprecating this at all. "Sure,  
>> Nathan,
>> it's like a filter," you say, "but is it really worth it to get  
>> rid of
>> it altogether?" Well, if you were to ask this, I would reply that  
>> yes,
>> yes it is worth it. There are several reasons to get rid of this:
>>
>>    1. It cluttered up the code. Checking for preserved text  
>> necessitated
>>       more than its fair share of logic precisely where we wanted the
>>       least logic. When we do eventually remove it, the code will  
>> become
>>       much neater.
>>    2. It was redundant. Everything it did could, and probably should,
>>       have been done with filters or helpers.
>>    3. It cluttered up Haml. Haml aims to be simple and easy to learn,
>>       and having lots of obscure commands doesn't help that at  
>> all. This
>>       is particularly true when the commands intuitively seem like  
>> they
>>       should be something other than commands (see point 2).
>>
>> We don't like deprecating stuff, and this is probably the only thing
>> we'll be deprecating in a good while, so don't worry about your views
>> breaking beyond this (if you use this... how many of you folks  
>> even knew
>> this command existed?).
>>
>> - Nathan
>
>
> >


--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to