Nevertheless, I think it would be nice to automatically preserve tags
that need it, even if it doesn't work for "= text_area" and friends.
Speaking of which, I just realized that we could simply modify the
text_area and text_area_tag helpers to always preserve their contents.
What does everyone think about that?
- Nathan
Robin wrote:
> Hi guys,
>
> Nathan, I was referring to what you were saying, but reading
> Hampton's
> reply, I realize it is not a great solution either.
>
> Even if the "magic tags" of %pre, %textarea and %code always preserved
> white space, any helper methods that generate those tags would not.
> The
> key one that comes to mind is =text_area, so my idea of throwing away
> the ~ operator cannot be done without the performance hit Hampton
> is talking about.
>
> I can't really think of a better way to do it, oh well!
>
>
> On May 4, 2:40 pm, "Nathan Weizenbaum" <[EMAIL PROTECTED]> wrote:
>
>> I believe Robin's referring
>> to making "%pre= foo" have an implicit "preserve", rather than having
>> "= render" have an implicit "find_and_preserve." That would certainly
>> be doable, at least performance-wise. I'm a little wary of adding
>> "magic tags," but I suppose if we add an option to turn it off it
>> could work.
>>
>> This also brings up the issue once again of a way to force Haml not to use
>> whitespace inside tags. I believe someone suggested a syntax like "%pre=
>> preserve foo -", which is similar to ERB. It worries me a little because
>> it's a bit ambiguous, and seems awkward for stuff like
>>
>> %ul
>> %li -
>> %a{:href => "#"} No whitespace outside me!
>>
>> Does anyone have any other suggestions?
>>
>> - Nathan
>>
>> On 5/4/07, Hampton <[EMAIL PROTECTED]> wrote:
>>
>>
>>
>>
>>> Robin-
>>>
>>> That was something I definitely considered very hard in the beginning.
>>> But, by the way ActionView works with render() being called
>>> recursively, it means that searching for these fields would have to
>>> take an aweful lot of processor power to accomplish. You'd have to
>>> scan the entire document at least 1-3 times on any render on any page.
>>> Also, *most* pages don't have <textarea> or <pre> tags. But, if they
>>> do, I wanted to make it easy to support.
>>>
>>> So, we chose not to do that because of the significant application
>>> slowdown that would be required. ~ is not a perfect solution, but its
>>> my favorite so far. In fact, the only downside is someone has to look
>>> into the API to find it.
>>>
>>> If you want to scan your entire document, just add "~ yield" where "=
>>> yield" is in your application layout file.
>>>
>>> Those are my thoughts. Thoughts from the community?
>>>
>>> -hampton.
>>>
>>> On 5/3/07, Robin <[EMAIL PROTECTED]> wrote:
>>>
>>>> The Problem:
>>>>
>>>> Let's say you have an instance variable, @blog_post, and you want to
>>>> show it in a <pre> tag:
>>>>
>>>> %pre~ @blog_post
>>>>
>>>> In this case, even though the ~ operator was used, the @blog_post
>>>> contents are indented using white space. The reason for this is that
>>>> the find_and_preserve method (~) only works when the content you're
>>>> evaluating contains a <textarea>, <pre> or <code> tag.
>>>>
>>>> I was pointed towards the preserve function, and it doesn't seem to
>>>> work in this case either:
>>>>
>>>> %pre= preserve(@blog_post)
>>>>
>>>> In this case, the new lines in @blog_post are converted to 
.
>>>> However, if @blog_post is longer than Haml::Buffer::ONE_LINER_LENGTH,
>>>> Haml indents it as well.
>>>>
>>>> Out there thought:
>>>>
>>>> While pondering all of this, I wondered to myself: is there a case
>>>> where someone would actually want white space inside a <textarea>,
>>>> <pre> or <code> tag? I certainly can't think of any. I think the
>>>> default behavior for these tags should be to _never_ process white
>>>> space within them.
>>>>
>>>> Maybe Haml shouldn't even have the ~ operator at all? If it could be
>>>> made smart enough to never add white space to tags where it matters,
>>>> and I believe it could, programmers wouldn't have to worry about
>>>> whether a tag needs white space or not, it would always just be there
>>>> except when it isn't appropriate.
>>>>
>>>> I think this would make learning Haml much easier, because it's
>>>> another thing people don't have to worry about.
>>>>
>>>> Thoughts?
>>>>
>
>
> >
>
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
