Clarification of how controllers and views work together...

[Bob Hutchison]

Thanks Ezra, I'll give it a shot this afternoon. Sorry for the  
delayed response, it has been crazy here.

Cheers,
Bob

On 12-Mar-07, at 3:01 AM, Ezra Zygmuntowicz wrote:

> Hey Bob-
>
> 	Let me explain what is happening. WHen you call render in your  
> controller action a new ViewContext instance is created. The  
> ViewContext takes the controller as an argument and copies all of  
> its instance variables into the VIewContext, then the same view  
> context is cached for the life of one request so subsequent renders  
> don't suffer the perf hit of making a new VIewContext.
>
> 	That being said, I will take a look and come up with a flag to  
> create a new viewcontext by passing in a flag.
>
> 	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.
>
>
> Index: lib/merb/mixins/render_mixin.rb
> ===================================================================
> --- lib/merb/mixins/render_mixin.rb     (revision 195)
> +++ lib/merb/mixins/render_mixin.rb     (working copy)
> @@ -78,7 +78,7 @@
>        engine = engine_for(template)
>        options = {
>          :file     => template,
> -        :view_context  => _view_context,
> +        :view_context  => (opts[:clean_context] ?  
> clean_view_context : _view_context),
>          :opts => opts
>        }
>        content = engine.transform(options)
> @@ -96,6 +96,10 @@
>        @_view_context_cache ||= ViewContext.new(self)
>      end
>
> +    def clean_view_context
> +      ViewContext.new(self)
> +    end
> +
>      # does a render with no layout. Also sets the
>      # content type header to text/javascript. Use
>      # this when you want to render a template with
>
>
>
> Cheers-
> -Ezra
>
>
> On Mar 11, 2007, at 9:10 PM, Bob Hutchison wrote:
>
>> Hi,
>>
>> So I've started mucking about with Merb. I'm doing some experimenting
>> with some product ideas. Things are working out quite well, Merb is a
>> pleasure to use. It seems very fast too. A couple of rough spots but
>> that might be me, if they are still chaffing after a few more days
>> I'll mention them.
>>
>> One thing...
>>
>> I wrote a controller and a view with several partials. Works fine.
>> Now lets say that I have to generate a bunch of static files that are
>> exactly like that page generated by that controller.
>>
>> So I generated an array of hashes, where each hash provides the
>> information needed by the views and partials. In a loop, I set an
>> instance variable, say @data, to each hash in the array then render
>> the view. It works the first time, subsequent times produce pages
>> identical to the first. I put a few puts in the view so I know it is
>> executing and isn't caching its results. When I look at object_ids
>> I'm starting to see what might be going on. The object_id of the
>> @data object is never the same as in the controller, and it never
>> changes during that request. Next request it is different but doesn't
>> change.
>>
>> Sounds like some kind of cache.
>>
>> Now, I'm thinking I'm either out of luck, or there is a trivial thing
>> I have to do to loosen the view's grip on that copy of @data that it
>> has.
>>
>> Any help is appreciated.
>>
>> Cheers,
>> Bob
>>
>> ----
>> Bob Hutchison                  -- blogs at <http://www.recursive.ca/
>> hutch/>
>> Recursive Design Inc.          -- <http://www.recursive.ca/>
>> xampl for Ruby                 -- <http://rubyforge.org/projects/ 
>> xampl/>
>>
>>
>>
>> _______________________________________________
>> Merb-devel mailing list
>> Merb-devel at rubyforge.org
>> http://rubyforge.org/mailman/listinfo/merb-devel
>
> -- Ezra Zygmuntowicz-- Lead Rails Evangelist
> -- ez at engineyard.com
> -- Engine Yard, Serious Rails Hosting
> -- (866) 518-YARD (9273)
>
>

----
Bob Hutchison                  -- blogs at <http://www.recursive.ca/ 
hutch/>
Recursive Design Inc.          -- <http://www.recursive.ca/>
xampl for Ruby                 -- <http://rubyforge.org/projects/xampl/>