PS: This started as a personal conversation with Nick Sutterer and Aaron Patterson, but I am sending to this mailing list as I think others may find this information useful. Nick, I could not control myself and pushed some initial code about what we discussed. ;) Yehuda have already started and defined some time ago a module called ActionView::Context. If you want to behave as an ActionView::Context, all you need to do is to include this module: https://github.com/rails/rails/blob/master/actionpack/lib/action_view/context.rb In order to make this context as slim as possible, I have created the view_renderer (as we discussed): https://github.com/rails/rails/blob/master/actionpack/lib/action_view/renderer/renderer.rb Which is now used in the controller: https://github.com/rails/rails/blob/master/actionpack/lib/abstract_controller/rendering.rb#L134 And here is an example of what is needed to render a controller sinatra style: https://github.com/rails/rails/blob/master/actionpack/test/controller/new_base/render_context_test.rb#L10-18 There is still a lot more to decouple: 1) There is still some controller - view context - view renderer coupling to iron out (but not a lot). 2) Test cases (AC::TestCase and AV::TestCase are extremely coupled). Particularly, AV::TestCase should be able to run against a minimal AV::Context. 3) Helpers are extremely coupled. If you try to use just one of the helpers in isolation, let''s say AV::Helpers::FormHelper, it is likely that it will fail because it does not have many dependencies. Ideally, we would use ActiveSupport::Concern and make such dependencies explicit, as happens in ActionController modules. José Valim www.plataformatec.com.br Founder and Lead Developer -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Cool, José. I started working on decoupling rendering and controller. For instance, AV::Renderer and friends shouldn''t need a controller instance. However, PartialRenderer relies on the controller - I don''t see the point why the PartialRenderer is responsible for finding a template. Isn''t that a concern for the LookupContext? I''d love to see the *Renderer being Renderer and nothing more. Any thoughts on this? In addition, is there any interesting in restructuring the view tests? I''d move things and make it more obvious where to find what. Nick On 1 Mai, 15:40, José Valim <jose.va...@gmail.com> wrote:> PS: This started as a personal conversation with Nick Sutterer and > Aaron Patterson, but I am sending to this mailing list as I think > others may find this information useful. > > Nick, I could not control myself and pushed some initial code about > what we discussed. ;) > > Yehuda have already started and defined some time ago a module called > ActionView::Context. If you want to behave as an ActionView::Context, > all you need to do is to include this module: > > https://github.com/rails/rails/blob/master/actionpack/lib/action_view... > > In order to make this context as slim as possible, I have created the > view_renderer (as we discussed): > > https://github.com/rails/rails/blob/master/actionpack/lib/action_view... > > Which is now used in the controller: > > https://github.com/rails/rails/blob/master/actionpack/lib/abstract_co... > > And here is an example of what is needed to render a controller > sinatra style: > > https://github.com/rails/rails/blob/master/actionpack/test/controller... > > There is still a lot more to decouple: > > 1) There is still some controller - view context - view renderer > coupling to iron out (but not a lot). > 2) Test cases (AC::TestCase and AV::TestCase are extremely coupled). > Particularly, AV::TestCase should be able to run against a minimal > AV::Context. > 3) Helpers are extremely coupled. If you try to use just one of the > helpers in isolation, let''s say AV::Helpers::FormHelper, it is likely > that it will fail because it does not have many dependencies. Ideally, > we would use ActiveSupport::Concern and make such dependencies > explicit, as happens in ActionController modules. > > José Valimwww.plataformatec.com.br > Founder and Lead Developer-- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> Cool, José. I started working on decoupling rendering and controller. > For instance, AV::Renderer and friends shouldn''t need a controller > instance. However, PartialRenderer relies on the controller - I don''t > see the point why the PartialRenderer is responsible for finding a > template. Isn''t that a concern for the LookupContext? I''d love to see > the *Renderer being Renderer and nothing more. Any thoughts on this?The PartialRenderer (or any renderer) is not really finding the template but it is simply preparing all the options that are used when finding the template. To prepare those options, it needs the controller. It should not be hard to decouple these two as the PartialRenderer only needs the class and prefixes from the controller. The prefixes could be stored in the lookup context object (as they are per se lookup information) and I believe the class could be swapped by "prefixes.first".> In addition, is there any interesting in restructuring the view tests? > I''d move things and make it more obvious where to find what.It is ok to restructure if we have clear benefits. I believe making "more obvious where to find what" is somehow subjective. :) -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> > In addition, is there any interesting in restructuring the view tests? > > I''d move things and make it more obvious where to find what. > > It is ok to restructure if we have clear benefits. I believe making > "more obvious where to find what" is somehow subjective. :) >In particular, I was thinking about the rendering tests in new_base/ and test/. -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Those tests were not refactored nor extracted from the old tests. They were basically new tests added during the Rails 3 refactoring. I think Yehuda was extremely against changing the tests structure because of things that could be lost. He had mentioned that in a presentation, I will check if I can find it. On May 4, 2:25 pm, Nick Sutterer <apoton...@gmail.com> wrote:> > > In addition, is there any interesting in restructuring the view tests? > > > I''d move things and make it more obvious where to find what. > > > It is ok to restructure if we have clear benefits. I believe making > > "more obvious where to find what" is somehow subjective. :) > > In particular, I was thinking about the rendering tests in new_base/ > and test/.-- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.