Route helpers in JS/CS assets

[Rodrigo Rosenfeld Rosas]

Are there any reasons why Rails doesn't have any route helpers available
for the JS/CS assets?

We're doing more and more client-side code and it is very likely that
you'll need to do something like "$.post products_path, params"
somewhere in your code.

Currently for doing that you'd need to create a file like
asset.js.coffee.erb and then do something like:

$.post <%= Rails.application.routes.url_helpers.send(:products_path) %>,
params

This is not only ugly and impractical, but I also don't want my files to
be processed with ERB. This is not even possible inside my ECO templates.

So I decided a while back to create a routes.js.coffee.erb to export my
named routes in some way to my other scripts. But as I needed more and
more features it got a lot messy now:

<% h = Rails.application.routes.url_helpers
{
sections_json: :json, fields_from_parent: :json_id, move_field: :json,
field: :json_id, field_save: :json, remove_field: :html_id,
field_aggregates_autocomplete: [:json_id, :data_type],
field_dependents_autocomplete: :json_id,
field_set_aggregator: [:html_id, :aggregator_id],
field_remove_aggregate: :html_id,
field_add_dependent: [:html_id, :dependent_id],
field_remove_dependent: [:html_id, :dependent_id],
section_update: :html_id, section_create: :json,
}.each do |named_route, options|
options = Array(options)
format = options.shift
format_options = {}
format_options[:format] = :json if format =~ /json/
options.push format_options
if format =~ /_id/ %>
window.<%= named_route %>_path = (id, options)->
path = "<%= h.send :"#{named_route}_path", '999', *options
%>".replace('999', id)
<% if options.size > 1 %>
path = path.replace(k, v) for k, v of options
path
<% end %>
<% else %>
window.<%= named_route %>_path = '<%= h.send
:"#{named_route}_path", format_options %>'
<% end %>
<% end %>


See how to maintain something like this can become complicated?

Couldn't Rails provide an easier built-in way for the named routes to be
easily exported as JS functions/variables?

This way, instead of each application define their own helpers for such
a common requirement, an official way would exist and developers moving
their jobs or projects would be aware where to look for.

I just feel there is some convention missing here.

Cheers,
Rodrigo.

[Steve Schwartz]

There are a couple gems and projects that do this:

* https://github.com/railsware/js-routes

* http://millermedeiros.github.com/crossroads.js/

I think this is likely outside the scope of rails core, given that most people doing ajax requests will be using the jquery-ujs or prototype-ujs helpers.

One of the issues why I would personally not use this is because, in order for it to work, you need to populate your JS with a list of all available routes throughout your app. For my own apps, I'd rather not have a list of all the applications' routes in plain text ready to be exploited. Sure, everything is locked-down and access-controlled, but I still don't necessarily want some random visitor knowing that registered group supervisors moderate their group's content via this URL, and approve members via that URL. And again, all of this could be handled by only serving specific JS URL helpers to specific users, but it ends up creating more work than it saves.

-- Steve Schwartz

--

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 rubyonra...@googlegroups.com.

To unsubscribe from this group, send email to rubyonrails-co...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.

[Rodrigo Rosenfeld Rosas]

Em 31-05-2012 17:11, Steve Schwartz escreveu:

There are a couple gems and projects that do this:

* https://github.com/railsware/js-routes

* http://millermedeiros.github.com/crossroads.js/

I think this is likely outside the scope of rails core, given that most people doing ajax requests will be using the jquery-ujs or prototype-ujs helpers.

I don't understand how is jquery-ujs related to this issue.

One of the issues why I would personally not use this is because, in order for it to work, you need to populate your JS with a list of all available routes throughout your app. For my own apps, I'd rather not have a list of all the applications' routes in plain text ready to be exploited.

I agree. I'm not suggesting that all routes should be exported, but I'd like to be able to easily decide which ones to export.

Sure, everything is locked-down and access-controlled, but I still don't necessarily want some random visitor knowing that registered group supervisors moderate their group's content via this URL, and approve members via that URL. And again, all of this could be handled by only serving specific JS URL helpers to specific users, but it ends up creating more work than it saves.

I'm not sure if you have a proper idea on how much saving is that...

Even if the idea of exporting the routes to a JavaScript files is not accepted, at least it should be easier to use the routes from an ERB asset.

"Rails.application.routes.url_helpers.send(:products_path)" is almost the same as an unsupported operation...

Kind regards,
Rodrigo.

[Pedro Nascimento]

Try `app.root_path`.

[Rodrigo Rosenfeld Rosas]

This only works in Rails console. Not in ERB views.

Steve, while crossroads.js is unrelated to this request, thank you very much for pointing me out js-routes.

I'll give it a try soon.

Cheers,
Rodrigo.

[Steve Schwartz]

You're right, I searched my bookmarks for "js rails routes" and that came up, my bad. There is another project that also does this, which was on Hacker News a while back I think, but I can't remember what it's called.

-- Steve Schwartz

[Simon de Boer]

I came to this same problem and think that it may perhaps need some convention...First my current solution to this.  Suggestion to Rails Core at the bottom.

My solution came from "defining" an api subdirectory/route namespace and that all routes under that namespace are ones to be exported to view clients.  The way I achieved this was by adding an #as_json to the Journey::Routes object, adding a RoutesController (in case the client needs to confirm/get updated routes at any point), plus setting a global route object in the JS of the served HTML.  (see the attached example file)

This returns an object that looks like this:

[ {:name=>"api_comments",

  :path=>"/api/comments(.:format)",

  :jsonp=>false, :verbs=>["GET"] },

{ :name=>"api_comment_cache",

  :path=>"/api/comments/:comment_id(/:commenter_id)(.:format)",

  :jsonp=>true, :verbs=>["GET"]}

]

Then I created a pared down version of the Rails router/parser on the JS end to find the right route for the given request method and fill in the necessary parameters.

Note I also needed to maintain which paths are called with JSONP because they need fully qualified URLs and a wholly different calling mechanism.  At this point it is just a specific list in the #as_json method.  It could be identified by another namespace, or something.

So....what is my actual suggestion to Rails Core?

That we could consider formalizing Routes#as_json/to_xml for this type of usage.  But, quickly, you get to considering implementing the whole Rails routes algorithm in JS for this to work in anything like an automatic process.

But, the goal of DRY routes, with the routes.rb file being in charge is a very appealing one.

[Jeremy Walker]

On 31 May 2012 14:10, Rodrigo Rosenfeld Rosas <rr.r...@gmail.com> wrote:

Are there any reasons why Rails doesn't have any route helpers available for the JS/CS assets?

We're doing more and more client-side code and it is very likely that you'll need to do something like "$.post products_path, params" somewhere in your code.

This sort of functionality strikes me as similar to the asset handlers (image-url etc) in sass-rails. As I understand it, sass-rails determines the correct url at runtime/compiletime by hooking into the application config.

Could routes be handled in a similar way, so that coffee-rails converts a route into a url at runtime/compiletime?

Maybe a reserved keyword or method is added to coffeescript (e.g. rails_routes) and then parsed when converting to JS. So...

$.get rails_route(products_path 1)

becomes:

$.get('/products/1')

This method would keep all the routes data on the server and avoids any duplication.

The similar other option would be to just check the coffeescript for any functions ending in _path or _url and then parse them accordingly. So...

$.get products_path(1)

becomes:

$.get('/products/1')

This has the advantage of being cleaner to code, but has two disadvantages: It could potentially lead to naming conflicts (but I think that this is probably an issue for the developer to avoid) and it would be probably be slower to compile.

tl;dr;

Hook into routes.rb while compiling CoffeeScript to Javascript and enable native feeling routes in CoffeeScript.

Thoughts?

Jeremy

 

--
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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com.

[Steve Schwartz]

tl;dr;

Hook into routes.rb while compiling CoffeeScript to Javascript and enable native feeling routes in CoffeeScript.

I think the problem there is that you wouldn't know to put "1" in there at asset compile time. It'd only work for un-nested collection paths like "/products".

-- Steve Schwartz

To post to this group, send email to rubyonra...@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-co...@googlegroups.com.

[Rodrigo Rosenfeld Rosas]

Em 01-06-2012 13:10, Steve Schwartz escreveu:

tl;dr;

Hook into routes.rb while compiling CoffeeScript to Javascript and enable native feeling routes in CoffeeScript.

I think the problem there is that you wouldn't know to put "1" in there at asset compile time. It'd only work for un-nested collection paths like "/products".

At least it would help a bit:

$.get rails_route(product_path(999).replace('999', id))

I actually like this idea. Even if it is not an ideal one...

Cheers,
Rodrigo.

[Jeremy Walker]

On 1 June 2012 17:10, Steve Schwartz <st...@alfajango.com> wrote:

tl;dr;

Hook into routes.rb while compiling CoffeeScript to Javascript and enable native feeling routes in CoffeeScript.

I think the problem there is that you wouldn't know to put "1" in there at asset compile time. It'd only work for un-nested collection paths like "/products".

But in the CoffeeScript, the developer will know the id of the resource they're calling.

So, the CS:

$.get project_path(project.id)

...could be pre-processed, using a lookup in routes.rb, into:

$.get "projects/#{project.id}"

...which then gets compiled to:

$.get "projects/" + project.id

And voila, you have a working solution. Am I missing something? :)

[Rodrigo Rosenfeld Rosas]

Em 01-06-2012 13:20, Jeremy Walker escreveu:

On 1 June 2012 17:10, Steve Schwartz <st...@alfajango.com> wrote:

tl;dr;

Hook into routes.rb while compiling CoffeeScript to Javascript and enable native feeling routes in CoffeeScript.

I think the problem there is that you wouldn't know to put "1" in there at asset compile time. It'd only work for un-nested collection paths like "/products".

But in the CoffeeScript, the developer will know the id of the resource they're calling.

So, the CS:

$.get project_path(project.id)

...could be pre-processed, using a lookup in routes.rb, into:

$.get "projects/#{project.id}"

...which then gets compiled to:

$.get "projects/" + project.id

And voila, you have a working solution. Am I missing something? :)

Yes, the id will be inside a JS variable. So if you have some constraints like /\d+/, it won't be able to check them...

[Jeremy Walker]

On 1 June 2012 17:22, Rodrigo Rosenfeld Rosas <rr.r...@gmail.com> wrote:

Em 01-06-2012 13:20, Jeremy Walker escreveu

But in the CoffeeScript, the developer will know the id of the resource they're calling.

So, the CS:

$.get project_path(project.id)

...could be pre-processed, using a lookup in routes.rb, into:

$.get "projects/#{project.id}"

...which then gets compiled to:

$.get "projects/" + project.id

And voila, you have a working solution. Am I missing something? :)

Yes, the id will be inside a JS variable. So if you have some constraints like /\d+/, it won't be able to check them...

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.

[Steve Schwartz]

tl;dr;

Hook into routes.rb while compiling CoffeeScript to Javascript and enable native feeling routes in CoffeeScript.

I think the problem there is that you wouldn't know to put "1" in there at asset compile time. It'd only work for un-nested collection paths like "/products".

But in the CoffeeScript, the developer will know the id of the resource they're calling.

So, the CS:

$.get project_path(project.id)

...could be pre-processed, using a lookup in routes.rb, into:

$.get "projects/#{project.id}"

...which then gets compiled to:

$.get "projects/" + project.id

And voila, you have a working solution. Am I missing something? :)

Yes, the id will be inside a JS variable. So if you have some constraints like /\d+/, it won't be able to check them...

I'm thinking aloud here, so bare with me.

You'd also need to be able to create coffeescript functionality for static [1] and dynamic segments [2], defining defaults [3], and using constraints of all types (segment constraints, request-based constraints, etc) like Rodrigo mentioned.

Though I'm not entirely convinced constraints would need to be handled, as in you'd get "route not found" on the response end if you didn't obey the constraint. The reason you'd need constraint checking on the request side (in the JS) would be so that it knows to select the next matching route down the list, which could possibly be considered an edge case to handle later. Maybe the other points I mentioned fall into the same category.

I think the point is, if you make route helpers available in coffeescript, people are going to expect *all* of the functionality of routes to work. Now I'm not intimately familiar with the innards of rails route compiling; maybe the fact that we're hooking into routes after they've already been generated by Rails makes these points easier to address.

But yes, I would think given enough time and code, you probably could make route helpers work in coffeescript at compile time. Also keep in mind, that this coffeescript functionality would need to be maintained and updated along side the core routes functionality.

The way I handle routes in my apps is to put the URLs in a data- attribute on the element being clicked or submitted (so I can use the core route helpers). Then, in my JS, I'd do:

$project = $('#project-link')

$.get ( $project.data('url') )

[1] http://guides.rubyonrails.org/routing.html#static-segments

[2] http://guides.rubyonrails.org/routing.html#dynamic-segments

[3] http://guides.rubyonrails.org/routing.html#defining-defaults

-- Steve Schwartz

--

[Rodrigo Rosenfeld Rosas]

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?

[Rodrigo Rosenfeld Rosas]

Em 01-06-2012 13:49, Steve Schwartz escreveu:

tl;dr;

Hook into routes.rb while compiling CoffeeScript to Javascript and enable native feeling routes in CoffeeScript.

I think the problem there is that you wouldn't know to put "1" in there at asset compile time. It'd only work for un-nested collection paths like "/products".

But in the CoffeeScript, the developer will know the id of the resource they're calling.

So, the CS:

$.get project_path(project.id)

...could be pre-processed, using a lookup in routes.rb, into:

$.get "projects/#{project.id}"

...which then gets compiled to:

$.get "projects/" + project.id

And voila, you have a working solution. Am I missing something? :)

Yes, the id will be inside a JS variable. So if you have some constraints like /\d+/, it won't be able to check them...

I'm thinking aloud here, so bare with me.

You'd also need to be able to create coffeescript functionality for static [1] and dynamic segments [2], defining defaults [3], and using constraints of all types (segment constraints, request-based constraints, etc) like Rodrigo mentioned.

Though I'm not entirely convinced constraints would need to be handled, as in you'd get "route not found" on the response end if you didn't obey the constraint. The reason you'd need constraint checking on the request side (in the JS) would be so that it knows to select the next matching route down the list, which could possibly be considered an edge case to handle later. Maybe the other points I mentioned fall into the same category.

I think the point is, if you make route helpers available in coffeescript, people are going to expect *all* of the functionality of routes to work. Now I'm not intimately familiar with the innards of rails route compiling; maybe the fact that we're hooking into routes after they've already been generated by Rails makes these points easier to address.

But yes, I would think given enough time and code, you probably could make route helpers work in coffeescript at compile time. Also keep in mind, that this coffeescript functionality would need to be maintained and updated along side the core routes functionality.

The way I handle routes in my apps is to put the URLs in a data- attribute on the element being clicked or submitted (so I can use the core route helpers). Then, in my JS, I'd do:

$project = $('#project-link')

$.get ( $project.data('url') )

I also use this technique, except when it is not possible.

When your application gets more complex, you'll need to do some interactions with the server without rendering any Rails partial view.

For example, I'm currently working in an application where the base html body is:

<div id=fields-tree></div>

And it will build the whole interface from CS, using ECO templates and will send tons of JSON requests to the server to get the data.

So, putting the url in data attributes is not a real option for this kind of application.

And this is not the first time I'm working on applications like this one.

I've been doing this since 2009 in almost all applications I've been working with since then.

And this is not just me. With exception of one application, all the other applications I've been worked with since 2009 were developed by different developers.

Given the raise of all those JS MVC-like frameworks and template libraries popping out all the time I'd say that this is a natural tendency for nowadays web applications.

And the lack of an easy way to use the routes in our client-side code makes Rails a not ideal framework for working with such kind of applications.

Not that I'd recommend any other web framework that is more suited to this task.

But this is an issue that should be addressed by Rails as this is how the web currently works or is moving towards this direction.

Best,
Rodrigo.

[Jeremy Walker]

On 1 June 2012 18:23, Rodrigo Rosenfeld Rosas <rr.r...@gmail.com> 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.

[Rodrigo Rosenfeld Rosas]

Em 01-06-2012 14:42, Jeremy Walker escreveu:

On 1 June 2012 18:23, Rodrigo Rosenfeld Rosas <rr.r...@gmail.com> 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...

[Rodrigo Rosenfeld Rosas]

Em 01-06-2012 15:20, Jeremy Walker escreveu:

On 1 Jun 2012, at 18:58, Rodrigo Rosenfeld Rosas <rr.r...@gmail.com> wrote:

Em 01-06-2012 14:42, Jeremy Walker escreveu:

On 1 June 2012 18:23, Rodrigo Rosenfeld Rosas <rr.r...@gmail.com> 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. 

No pressure at all :) I'm using a patched version of js-routes right now:

https://github.com/railsware/js-routes/pull/46

I'd certainly appreciate your effort on that, but I'd just like to advice you on thinking about the solution in the Rails side first as I guess this is the hardest part.

You can take a look at the js-routes source code to have some ideas though.

[Jeremy Walker]

On 1 Jun 2012, at 18:58, Rodrigo Rosenfeld Rosas <rr.r...@gmail.com> wrote:

Em 01-06-2012 14:42, Jeremy Walker escreveu:

On 1 June 2012 18:23, Rodrigo Rosenfeld Rosas <rr.r...@gmail.com> 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...

--

[Jeremy Walker]

No pressure at all :) I'm using a patched version of js-routes right now:

https://github.com/railsware/js-routes/pull/46

I'd certainly appreciate your effort on that, but I'd just like to advice you on thinking about the solution in the Rails side first as I guess this is the hardest part.

You can take a look at the js-routes source code to have some ideas though.

I've not had very much time on this, so sorry for the delay. I've knocked together a repository and a gist to explain what I'm suggesting. If you want to add a pull request with any failing tests, I'll try and get them passing. 

To recap, I'm imagining this sits as a library that is added to coffee-rails, that CoffeeScript is populated with reserved methods matching the names of the routes, and when one is encountered it calls the parse method to convert it to more CS or JS. I'm making assumptions about how CS does stuff and I think that should be the next piece of investigation.

However, this is basically how I'd approach from the Rails side of things. It's extremely simple...

https://gist.github.com/2882545

https://github.com/ihid/rails-coffeescript-routes

Your thoughts/feedback are welcome :)

[Rodrigo Rosenfeld Rosas]

Great, Jeremy. I'll take a look at it when I find some free time. But I guess this approach won't work for routes with constraints like /\d+/, but maybe the format method you're using won't check for constraints...

Cheers,
Rodrigo.