This definitely shouldn't be happening, but I'm not sure the cause is what you think it is. _erbout is just an alias for the internal Haml buffer, which is what capture_haml manipulates. I can't reproduce this, or I'd test it out - can you come up with a simple template and helper that demonstrate the issue (and don't rely on Rails)?
On Mon, Aug 31, 2009 at 5:48 PM, Emmanuel Gomez <[email protected]>wrote: > > Hi, > > In a Rails app I'm working on, we've been using haml-edge 2.1.3 > (frozen in vendor/gems). This morning, I upgraded our app to Haml > 2.2.3 (also frozen in vendor/gems). > > Everything worked fine on my development machine and on our staging > server, but when deployed to production, we started seeing an issue: > in one of our actions where we use #capture_haml, the content of the > template was being outputted before the layout. > > After digging around a little, we found lib/haml/precompiler.rb line > #300: > "_erbout << \"#{text}\";" > On a whim, we changed that to: > "_hamlout.push_text(\"#{text}\", 1, false);" > and our output problems disappeared. > > It appears that appending to `_erbout` bypasses some important step, > as if it were outputted directly and not available for #capture_haml, > but only when `...@options[:ugly]` is true (ie., it happens when > RAILS_ENV == "production"). > > Has anyone else seen this issue? If so, is there a more official/ > supported/elegant way to fix this? > > Most importantly, can anyone tell me if my production server will > ignite in a ball of fire if I deploy this one-line hack? > > > Thank you, > Emmanuel Gomez > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
