The thing is, filters exist expressly so that non-Haml syntaxes can be used from within Haml. Using them to do processing on Haml code is wrong; not only is it much easier with a helper method, that's what helper methods are /for/.
Also, could you work up unit tests for the rest of your patches? Thanks. - Nathan Bob Aman wrote: >> This is an interesting way to solve that problem. Why not go with a >> helper function? >> >> - online do >> whatever >> >> - Nathan >> > > Because I wanted the stuff within the "oneline" construct to be > specified as Haml. It seemed inelegant to me to have to drop into > Ruby when the content wasn't even dynamic to overcome what I felt was > a minor limitation of the templating system. Seemed to make more > sense to just go ahead and remove the limitation. > > For example, what if I had: > > :oneline > %pre > %code > :preserve > # This is some static ruby code > # which I want to display for the > # world to see. > puts eval(2 + 2) > > Surely you don't disagree that that is a much nicer way of outputting > "<pre><code># This is some static ruby code
# which I want to > display for the
# world to see.
puts eval(2 + > 2)
</code></pre>\n" than it would be if I tried to use a helper > method to generate that. > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
