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