Limitation with RC named routes -good time to switch horses?
Chris Hapgood
But I do think there is some merit in exploiting the work going into
the polymorphic_url method in RoR. Here's an example of a problem I
have that could almost be solved by polymorphic_url.
Let's use my wheels example...
map.resource :cars do |car|
car.resources :wheels
end
map.resource :motorcycles do |motorcycle|
motorcycle.resources :wheels
end
Now imagine you have a partial for rendering the elements of the
wheels collection. In the view for CarsController.show, I do this:
render :partial 'wheel' :collection => @wheels
The _wheel partial provides a link to edit a wheel, so I use
edit_resource_wheel_url -and it works great.
The problem comes when I edit the wheel in WheelsController.edit and
try to render the partial for an RJS update. Since self.resource is
now a wheel, RC expands the named route into edit_wheel_wheel_url -
which of course bombs out.
The gist of this problem is simple: sometimes partials are rendered
within the context of a resource X and sometimes they are rendered
within the context of resource X's parent. Rails addresses the
problem by allowing local variables to be set in the render :partial
method.
POSSIBLE SOLUTIONS
1. One solution to this problem might be to mimic Rails' ability to
set local variables within a partial: allow the resource to be set to
a subordinate resource in the context of the partial. I think this
would be hard because the controller and thus the
resources_controller_for information is only available for the parent
resource.
2. Another solution, and the one that I think has more longevity, is
to harness polymorphic_url's power to dynamically construct a route
for an array of AR objects. From my example above, in both the
CarsController and the WheelsController I would need an array like
this:
[<Car instance>, <Wheel instance>]
In the CarsController, I would need to construct the array with
self.resource (for the Car instance). The Wheel instance would be the
local variable that Rails provides in the partial. Same goes for the
MotorcyclesController.
In the WheelsController, I would need to construct the array with
self.enclosing_resource (for the Car instance) and the Wheel instance
would again be the local variable.
The problem is that polymorphic_url is restricted to operating on
routes whose name match exactly the classes of the presented AR
records. It can't handle the wide variety of polymorphism (despite
the name) and aliasing that RC can handle. For example, if I used a
single Vehicle class to handle both the Car and Motorcycle routes,
polymorphic_url dies -it can't find an explicit vehicle_wheel_url.
So what if we combine the best of both worlds? Would it be possible
for RC to provide a method like polymorphic_url (that can operate on a
dynamically constructed array of resources) but more capable of
dealing with the inevitable lexical vagaries? It should be able to
take input like this:
rc_url([@v, @w])
and convert it to a named route like this:
car_wheel_url(<Vehicle instance>, <Wheel instance>)
It knows that even though @car is an instance of Vehicle, it was
derived from the car segment of the route and should be mapped right
back to a car route.
--------
I know I rambled a bit, so I'll try for a quick summary: provide a
route builder method that operates on an array of AR objects and knows
how to work backwards from their classes. It uses the specifications
already provided to resources_controller_for and nested_in to achieve
the effect.
Ian White
> route builder method that operates on an array of AR objects and knows
> how to work backwards from their classes. It uses the specifications
> already provided to resources_controller_for and nested_in to achieve
> the effect.
In lieu of a full digest... be my guest, and submit a well tested patch
Cheers,
Ian
--
Argument from Design--We build web applications
Western House 239 Western Road Sheffield S10 1LE UK
Mobile: +44 (0)797 4678409 | Office: +44 (0)114 2667712
<http://www.ardes.com/> | <http://blog.ardes.com/>
Ian White
> > route builder method that operates on an array of AR objects and knows
> > how to work backwards from their classes. It uses the specifications
> > already provided to resources_controller_for and nested_in to achieve
> > the effect.
changing the resource context.
Example: I want to render a comment from the context of commentable,
and comment (on rjs action). I want the named route helpers to be the
same in both cases (edit_resource_path)
in posts/show.html.erb
<% with_resource_context :resource_comments do %>
<%= render :partial => 'comments/comment', :collection =>
resource.comments
<% end %>
in comments/comment.html.erb
<% div_for comment %>
<%= comment.body %>
<% link_to edit_resource_path(comment) %>
<% end %>
in comments/show.rjs
page.replace dom_id(resource), :partial => 'comment', :object =>
resource
The heavy lifting will be in with_resource_context, essentially it
would provide a context where enclosing_resources, and
resource_speicifaction change to match the specified context.
Thoughts?
Ian
Chris Hapgood
And I do like the idea of a with_resource_context method yielding to a block
-although consistency with RoR might suggest with_resource_scope, or even
just with_scope (where the context should make it obvious one is scoping RC
not AR).
Chris Hapgood
Phone: +1 434 989 8584
Skype: chris.hapgood
Email: cc...@hapgoods.com
in posts/show.html.erb
in comments/comment.html.erb
in comments/show.rjs
Thoughts?
Ian
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.503 / Virus Database: 269.17.4/1188 - Release Date: 17/12/2007
14:13
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.503 / Virus Database: 269.17.4/1188 - Release Date: 17/12/2007
14:13
Brian
On Dec 18 2007, 10:33 am, "Chris Hapgood" <c...@hapgoods.com> wrote:
> You have grokked my suggestion perfectly.
>
> And I do like the idea of a with_resource_context method yielding to a block
> -although consistency with RoR might suggest with_resource_scope, or even
> just with_scope (where the context should make it obvious one is scoping RC
> not AR).
>
> Chris Hapgood
> Phone: +1 434 989 8584
> Skype: chris.hapgood
Ian White
Not yet, it's on the cards though :)
Currently RC is being reworked, and part of this is investigating
simplification of the resource_path stuff to bypass named routes, and
access the url generation stuff directly.
I'll be moving RC into its own repo so that people can have access to
tagged stable versions.
I'll post about new repo location, and what's coming up, soon (the
current location will continue to work).
Cheers,
Ian
--
Argument from Design--We build web applications
Western House 239 Western Road Sheffield S10 1LE UK
Mobile: +44 (0)797 4678409 | Office: +44 (0)114 2667712