On 1 June 2012 18:23, Rodrigo Rosenfeld Rosas <[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.
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.
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.
--
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.
