I'm sorry, I was mistaken. Mislav's right: you'll need to use capture_haml
to do this. The issue is that Haml doesn't actually reassign the buffer
variable within the scope of the block.

On Sun, May 2, 2010 at 1:50 PM, Don Sheehy <[email protected]> wrote:

> Thanks to both Mislav and Nathan.  Mislav's suggestion worked for me.  I
> tried to use the common scope approach that Nathan mentions but I couldn't
> get it to work.  For example I tried the following snippet:
>
> scope = Object.new
>
> def scope.layout
>
>   layout_engine = Haml::Engine.new(IO.read("layout.haml"))
>   layout_engine.render(self){ yield }
>
> end
>
> engine = Haml::Engine.new(IO.read("index.html.haml"))
> puts engine.render(scope)
>
> ----------OUTPUT------------
>
> <h1>Before the container</h1>
> <h1>Inside the container.</h1>
> <div id='container'>
>   false
> </div>
>
> This was actually what I had tried initially to get my head around this
> scoping pattern.  Have I perhaps missed something simple?
> Thanks again,
> Don
>
>
> On Sun, May 2, 2010 at 3:29 PM, Nathan Weizenbaum <[email protected]>wrote:
>
>> Mislav is correct: the yield is yielding to code that appends to the outer
>> Haml buffer, not the inner. However, there is an easier way to handle this
>> than with haml_capture. You just need to make sure that both the layout and
>> the main page are rendering with the same scope object (see
>> http://haml-lang.com/docs/yardoc/Haml/Engine.html#render-instance_method).
>> If this is the same across both instances of Engine, the Haml buffers will
>> be set up properly.
>>
>> Note that if you're planning to use Haml to render a page during each
>> request in a production website, you should definitely use
>> Haml::Engine#def_method in preference to #render, and remember to cache the
>> defined methods.
>>
>>
>> On Sun, May 2, 2010 at 11:46 AM, Mislav Marohnić <
>> [email protected]> wrote:
>>
>>> On Sun, May 2, 2010 at 20:15, Don <[email protected]> wrote:
>>>
>>>>
>>>> def layout
>>>>  layout_engine = Haml::Engine.new(IO.read("layout.haml"))
>>>>  haml_concat layout_engine.render{ yield }
>>>> end
>>>
>>>
>>> Interesting experiment. I think it didn't work for you because the
>>> `layout do ... end` block carried its context with it (remember closures)
>>> and when it yielded, it still appended to the original template instead to
>>> "layout.haml".
>>>
>>> In my opinion, the only way this could work is that you use
>>> `haml_capture` to capture the actual result and pass it in a block to
>>> `layout_engine.render`. Yeah, falling back to raw strings doesn't seem
>>> elegant, but it might be the only solution here. I'm pretty much convinced
>>> that's how it works in Rails views, for instance.
>>>
>>> --
>>> 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] <haml%[email protected]>.
>>> For more options, visit this group at
>>> http://groups.google.com/group/haml?hl=en.
>>>
>>
>>  --
>> 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] <haml%[email protected]>.
>> For more options, visit this group at
>> http://groups.google.com/group/haml?hl=en.
>>
>
>  --
> 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] <haml%[email protected]>.
> For more options, visit this group at
> http://groups.google.com/group/haml?hl=en.
>

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

Reply via email to