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