I submitted a patch some time ago that I''d like some feedback on. It seems like a good idea to me that we make an official way to provide alternate paths for view files. A lot of hacks have cropped up that could be consolidated (e.g. the "Falling through to default templates" thread, engines, plugins and my productized rails work all use this sort of a hack). http://dev.rubyonrails.org/ticket/2754 Duane Johnson (canadaduane) _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Sounds pretty reasonable to me. Couple thoughts: I know that the Globalize plugin uses template.en-US.rhtml, template.es-MX.rhtml, etc. To me this is preferable to en-US/template.rhtml. That would lead to a lot of extra folders lying about. Can we use a patch like this to enable this behavior? This is a minor concern, but one I think others would raise too. Should this be specified on an application-wide basis, or on a request-by-request basis, perhaps mediated by before_filters? Kyle On 12/12/05, Duane Johnson <duane.johnson@gmail.com> wrote:> I submitted a patch some time ago that I''d like some feedback on. It seems > like a good idea to me that we make an official way to provide alternate > paths for view files. A lot of hacks have cropped up that could be > consolidated (e.g. the "Falling through to default templates" thread, > engines, plugins and my productized rails work all use this sort of a hack). > > http://dev.rubyonrails.org/ticket/2754 > > Duane Johnson > (canadaduane) > _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core > > >
On Dec 12, 2005, at 5:01 PM, Kyle Maxwell wrote:> Sounds pretty reasonable to me. Couple thoughts: > > I know that the Globalize plugin uses template.en-US.rhtml, > template.es-MX.rhtml, etc. To me this is preferable to > en-US/template.rhtml. That would lead to a lot of extra folders lying > about. Can we use a patch like this to enable this behavior? This is > a minor concern, but one I think others would raise too. > > Should this be specified on an application-wide basis, or on a > request-by-request basis, perhaps mediated by before_filters? > > Kyle >Interesting idea, Kyle. I think the best way to accomplish what you''re suggesting is some way of embedding a ''proc'' in to the alternate path array. So, in essence, while my patch would currently allow someone to do this: ActionView.alternate_base_paths_before << RAILS_ROOT + ''/special/ location'' We should enable people to use it like this also: ActionView.alternate_base_paths_before << proc { |controller| RAILS_ROOT + "/app/views/#{controller.language}/" } This makes use of the folder method (instead of the filename method) that you seemed to not prefer as much, but it would be a lot easier to implement. As you suggested, the above method would rely on some before_filter setting a cattr_attribute (such as :language) so that our base path could be configured on a per-request basis. Duane Johnson (canadaduane)
My thoughts for implementation are something like this (I guess it
only covers the before case, but it should communicate the idea):
module ActionView
class Base
alias_method :old_render_file, :render_file
def render_file(template_path, use_full_path = true, local_assigns = {})
if new_path = alternate_path(template_path)
# don''t use_full_path -- we''ve already expanded the
path
old_render_file(new_path, false, local_assigns)
else
old_render_file(template_path, use_full_path = true, local_assigns)
end
end
private
def alternate_path(template_path)
ActionView.alternate_base_paths_before.each do |p|
path = ""
if p.is_a?String
path = p + template_path
elsif p.is_a?Proc
path = p.call(template_path)
end
return path if File.exists?(path)
end
end
end
end
On 12/13/05, Duane Johnson <duane.johnson@gmail.com>
wrote:>
> On Dec 12, 2005, at 5:01 PM, Kyle Maxwell wrote:
>
> > Sounds pretty reasonable to me. Couple thoughts:
> >
> > I know that the Globalize plugin uses template.en-US.rhtml,
> > template.es-MX.rhtml, etc. To me this is preferable to
> > en-US/template.rhtml. That would lead to a lot of extra folders lying
> > about. Can we use a patch like this to enable this behavior? This is
> > a minor concern, but one I think others would raise too.
> >
> > Should this be specified on an application-wide basis, or on a
> > request-by-request basis, perhaps mediated by before_filters?
> >
> > Kyle
> >
> Interesting idea, Kyle.
>
> I think the best way to accomplish what you''re suggesting is some
way
> of embedding a ''proc'' in to the alternate path array.
So, in
> essence, while my patch would currently allow someone to do this:
>
> ActionView.alternate_base_paths_before << RAILS_ROOT +
''/special/
> location''
>
> We should enable people to use it like this also:
>
> ActionView.alternate_base_paths_before << proc { |controller|
> RAILS_ROOT + "/app/views/#{controller.language}/" }
>
> This makes use of the folder method (instead of the filename method)
> that you seemed to not prefer as much, but it would be a lot easier
> to implement. As you suggested, the above method would rely on some
> before_filter setting a cattr_attribute (such as :language) so that
> our base path could be configured on a per-request basis.
>
> Duane Johnson
> (canadaduane)
> _______________________________________________
> Rails-core mailing list
> Rails-core@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails-core
>