Em 01-06-2012 14:42, Jeremy Walker escreveu:
On 1 June 2012 18:23, Rodrigo Rosenfeld Rosas <[email protected]
<mailto:[email protected]>> wrote:
Em 01-06-2012 13:45, Jeremy Walker escreveu:
Good point. Am I correct in saying that the only time this is a
real issue is if someone defines two routes, with the same name,
but different paths, e.g.
match '/products/:id' => 'products#show', :constraints => {:id
=> /\d/}, as: "product"
match '/products/:id/extra' => 'products#show', as: "product"
In other situations, the generated path will be the same, and the
server will still check the constraint if/when the request is
sent, so the developer loses a little compile-time type-safety,
but everything stays safe/secure.
Obviously, the two different routes with the same name thing is
an issue, but that idiom strikes me as a bit odd/risky in the
first place.
Yeah, that would work.
I just thought you were suggesting to use produc_path(id) for
implementing this feature. In that case, it would raise an
exception if id is not a number.
How are you thinking about the implementation of such feature
while processing CS?
Also, what if someone still wants to keep using JS instead of CS?
How would it be possible for them to take advantage of the asset
pipeline route helpers?
I honestly don't know enough about CS internals to specifically say
how I'd implement it. However, the two methods I'd initially explore
would be:
1) Monkey-patch the compiler to recognise the routes' names as
keywords/methods and then either process them for more CS compilation,
or process them straight to JS. This method depends a lot on how the
compiler has been written and how extendable it is. I would imagine
that recognising new nodes as it parses is pretty standard, but it's
how easy it is to insert that functionality in. I imagine 30mins of
browsing through code would tell you if it was feasible.
2) Pre-processing the CS to look for the method names by regex and
then convert them to CS, before the processing starts. This method is
a bit more brute-force and lots more error prone. I can think of lots
of stuff that would go wrong. I'd consider it a last-ditch idea in
case the CS compiler wasn't easily monkey-patchable.
Sorry, but that was not my concern when I asked you about the
implementation.
I'd like to know how you think this should be implemented in the Rails side.
Given that the CS compiler detected "product_path(id)", how should it
proceed to replace it with JS or CS code?
With regards to JS instead of CS. My initial reaction is, they
wouldn't be able to. As Rails now supports CS out of the box (it's in
the generated Gemfile), then I'd expect people to be ok with
technologies being built into that. If you want to not use the default
Rails JS library (CoffeeScript), then you don't get all the features.
However, if people felt it needed to be build in, then you could use
either methods 1 or 2, using a JS interpreter for method 1.
I'm not sure. I don't write JS anymore myself, but I can understand
those who don't want or feel the need to use CS. Also, someone could
want to edit some existent JS to change some fixed path by one generated
by the route helpers.
An option for them would be to create a routes.js.coffee file just for
storing the generated paths in some variables and require this file
before any other JS using those paths...
If this is a solution that the Core team feel is worth exploring
further, then I'm happy to set some time aside to seriously explore it
more. Saying that, there are lots of people who know the internals of
CoffeeScript and could probably verify how easy it will be to do
without much effort.
I'd rather discuss the Rails-side implementation effort first, as I
guess this could be the hardest part instead of the CS integration one...
--
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.
