Clarification of how controllers and views work together...

[Ezra Zygmuntowicz]

On Mar 17, 2007, at 7:42 AM, Bob Hutchison wrote:

> Hi Ezra,
>
> On 12-Mar-07, at 3:01 AM, Ezra Zygmuntowicz wrote:
>
>> 	Ok I took a look. Here is a patch for you to try before I commit  
>> it to the repo. The default behavior remains the same and the  
>> viewcontext is cached for subsequest renders. But if you pass  
>> in  :clean_context => true  along with your render method you will  
>> get a fresh context with your current ivars as you expect.
>>
>
> That worked perfectly. Thanks!
>
> Just wondering... what do you gain by caching the ViewContext?  
> Well, more precisely, when would the output of the render be  
> different when using the cached ViewContext? Doesn't the  
> ViewContext pretty much control the input to the rendering?  ... I  
> suppose some of the view's input could be computed by calls (that  
> changed the state of something, otherwise the result of the call  
> would always be the same) made by the view but is that a good idea?
>
> Cheers,
> Bob


Hey Bob-

	If we don't cache the view context then layouts will not work  
properly. The views that have layouts are rendered in a 2 step  
process. First the inner template is rendered and an instance var is  
set on the cached view context so when the layout gets rendered that  
ivar is expanded to the layout content. If the view context is not  
cached the layout will be empty, and its a performance hit to copy  
ivars over twice.

	You will notice rails does something similar by only allowing you to  
render once. I don't limit you to rendering once and merb renders  
just return strings and merb actions send whatever their return value  
is to the browser.

Cheers-
-- Ezra Zygmuntowicz 
-- Lead Rails Evangelist
-- ez at engineyard.com
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)