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
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
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. 
> 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/.
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.