That's exactly what I'd like to do: make the entire partial unindented. I envision a | mark resetting the indentation level for the tag it's used on; if there are nested tags, they would still be indented, but relative to the reset level. When used with my ERb partials, I'm basically saying that I'm taking indentation into my own hands, which is precisely what I require for my preformatted text.
I'll look into writing an unpreserve helper, but I still like the (perceived) elegance of my | suggestion. Thanks for your time. On Oct 24, 1:59 pm, Nathan Weizenbaum <[email protected]> wrote: > Converting the partials to ERB isn't going to help, since (as you noted) the > issue comes from the Haml layout re-indenting the code. I don't see how a > syntactic marker could help this, unless you want the entire partial to be > un-indented. A better solution would be to make an unpreserve helper that > you wrap your partial calls in in the layout that converts newline entities > into actual newlines. > > > > On Sat, Oct 24, 2009 at 1:24 PM, Twisol <[email protected]> wrote: > > > I've converted the offending preformatted partials back to ERb, since > > this seems like a good place for it. Now my only issue is the > > indentation, because the layout file is still Haml. If the | mark I > > suggested was added, to reset indentation, it would make it easier to > > include ERb partials like this, and my problem would be duly solved. > > > On Oct 24, 1:21 pm, Nathan Weizenbaum <[email protected]> wrote: > > > Potentially, yes, but that would dramatically increase the cost of string > > > concatenation, which is something we desperately want to avoid, since > > string > > > concatenation happens a lot during the rendering of a Haml template. > > > > On Sat, Oct 24, 2009 at 1:19 PM, Chris Eppstein <[email protected]> > > wrote: > > > > Can't haml have some concept of a pre-formatted bit that gets set and > > then > > > > is sticky for the rest of the handling of that template? If the bit is > > set, > > > > haml layouts wouldn't re-indent those strings. This decision could be > > made > > > > dynamically and helpers could be made to help manage the formatting > > bit. > > > > > chris > > > > > (Implementation suggestion: haml can return an extended string object > > for > > > > tracking the state of preformatting) > > > > > On Sat, Oct 24, 2009 at 1:10 PM, Nathan Weizenbaum <[email protected] > > >wrote: > > > > >> First of all, filters like :preserve aren't meant for handling > > > >> dynamically-generated text; they're meant for handling literal, > > in-template > > > >> text with maybe some dynamic stuff sprinkled in. If you're dynamically > > > >> generating text, it's better to use the #preserve helper (or ~, which > > is a > > > >> shortcut for same). > > > > >> As for the source code aesthetics, as I mentioned on IRC, there's > > really > > > >> no good way to tell when it's possible to not use newline entities. > > > >> Declaring it in the template won't work, because it's *not* safe in > > that > > > >> template - the template still needs to be included in the layout, > > which will > > > >> re-indent it and cause the whitespace to go wrong. The only potential > > > >> solution is to have some way of declaring "this template is never > > going to > > > >> be included in another template", something that might be added in the > > > >> future. > > > > >> On Sat, Oct 24, 2009 at 12:47 PM, Twisol <[email protected]> wrote: > > > > >>> Hello, > > > > >>> So far I really love Haml, but I have an issue with it where it comes > > > >>> to preformatted text.I have a fairly large amount of preformatted > > text > > > >>> (generated on the fly by a Rails helper) that I'm trying to include > > > >>> into my page. Using the :preserve filter, it /looks/ fine, but in the > > > >>> source it's all on one line, word-wrapped to about thirty, and > > > >>> completely indecipherable. > > > > >>> I discussed this briefly with Nex3 on IRC, but he had to run. While > > > >>> writing this message, though, I did have an idea: would it be > > possible > > > >>> to add another tag prefix, using either a _ (underscore) or a | > > > >>> (pipe), to tell Haml that the tag's indentation (or at least its > > > >>> content) should be reset? Nex3 had mentioned that Haml couldn't > > > >>> determine when it was safe to perserve the literal newlines because > > it > > > >>> automatically indents text, but if you used | to reset indentation, > > it > > > >>> seems like it would be safer for Haml to do. If that was possible, I > > > >>> think "%pre|<" would work perfectly for my purposes. > > > > >>> Otherwise, some advice would be very much appreciated! Thanks in > > > >>> advance, > > > >>> ~Jonathan Castello --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
