As far as I can tell, Haml's behaving the same way that Rails does. It's not very good behavior, but I think in this case consistency is better than sanity.
On Wed, Feb 4, 2009 at 2:12 PM, Nathan Weizenbaum <[email protected]> wrote: > I'll look into this... there are some weird logic issues going on here. > > > On Wed, Feb 4, 2009 at 11:00 AM, Victor Moroz <[email protected]> wrote: > >> >> As I found, same can be done the way which works in 2.0.6 >> >> def helper_method( &haml_block ) >> html = capture &haml_block >> ... >> >> But the idea was not to just yield inside this new block as I showed >> in the previous post, but to call another helper method inside capture >> block with &haml_block as a parameter, and this won't work anyway. Is >> there any other way to check that block is producing haml result >> except for eval( '_hamlout', block.binding )? In my previous post >> block.binding is not haml, but result is still going to _hamlout and >> should be processed by capture_haml. Why not check both buffers after >> block execution and take whichever is not empty? >> >> >> > Helper: >> > >> > def helper_method >> > html = capture do >> > yield >> > end >> > ... processing html, html is nil here >> > end >> > >> > Haml: >> > >> > - helper_method do >> > %div >> > .... >> >> >> >> > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
