On 5-okt-2007, at 1:28, Rick Olson wrote:

>
> I think it actually makes more sense if ActionView::Base gets a duped
> view_paths though.  It establishes that the controller class
> view_paths are the default, while the controller instances's
> view_paths only affect that request:

Not to be rude, but this solution seems half-cooked (or half-baked)  
to me. It's still a hack.
Why don't we abolish the view_paths altogether in favor of some  
solution that is
a) encapsulated
b) officially overridable
c) does not muck with inheritable class_vars

That is: 1 template path per controller point (what we had in rails  
1.2.3), the rest via a lookup object that responds to partial_path,  
action_path, layout_path and mail_path.
This way you escape the mess and give people enough flexibility. The  
way in which the lookup object can be implemented is left totally to the
developer of the application. This way you also remove a substantial  
layer of complexity from _both_ ActionView and ActionController, you  
avoid
GC problems that you mentioned and you don't make "workaround"  
solutions where no workarounds are needed (this is should not be so  
convoluted!)
The only thing you need is: 1 ivar per request (the template lookup  
object) and _proper_ path support for ActionView (published way to  
feed it absolute paths).

render :action => '/foo/bar/baz' # we know that "/" means RAILS_ROOT/ 
app/views point, no exception - you can compute the path to anything  
_from there_
render :action => 'foo/bar/baz' # we use the template finding  
implemented in Rails 1.2.3

A solution like that seems also in line to the latest Rails  
improvements (implementing plugin hooks and extracting instead of  
making more layers upon layers of indirection).

-- 
Julian 'Julik' Tarkhanov
please send all personal mail to
me at julik.nl



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" 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/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to