On 1 Jun 2012, at 18:58, Rodrigo Rosenfeld Rosas <[email protected]> wrote:
> Em 01-06-2012 14:42, Jeremy Walker escreveu: >> >> >> >> 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. > > 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? Ok, give me an evening to read the internals of routing and I'll come back to you with some suggestions/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. -- 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.
