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