Rails core - May 2012 - Route helpers in JS/CS assets

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.

-- 
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.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

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


On Thursday, May 31, 2012 at 9:10 AM, Rodrigo Rosenfeld Rosas 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.
> 
> 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.
> 
> -- 
> 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
(mailto:rubyonrails-core@googlegroups.com).
> To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
(mailto:rubyonrails-core+unsubscribe@googlegroups.com).
> 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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

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.
>
> On Thursday, May 31, 2012 at 9:10 AM, Rodrigo Rosenfeld Rosas 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.
>>
>> 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.
>>
-- 
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.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

Try `app.root_path`.

On Thu, May 31, 2012 at 5:19 PM, Rodrigo Rosenfeld Rosas
<rr.rosas@gmail.com
> wrote:
>  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.
>
>
>
>  On Thursday, May 31, 2012 at 9:10 AM, Rodrigo Rosenfeld Rosas 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.
>
>  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.
>
>
>  --
> 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.
> 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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

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.

Em 31-05-2012 17:33, Pedro Nascimento escreveu:
> Try `app.root_path`.
>
> On Thu, May 31, 2012 at 5:19 PM, Rodrigo Rosenfeld Rosas 
> <rr.rosas@gmail.com <mailto:rr.rosas@gmail.com>> wrote:
>
>     Em 31-05-2012 17 <tel:31-05-2012%2017>: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.
>
>
>>
>>     On Thursday, May 31, 2012 at 9:10 AM, Rodrigo Rosenfeld Rosas
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.
>>>
>>>     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.
>>>
-- 
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.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

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


On Thursday, May 31, 2012 at 4:38 PM, Rodrigo Rosenfeld Rosas wrote:
> 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.
> 
> Em 31-05-2012 17:33, Pedro Nascimento escreveu: 
> > Try `app.root_path`.
> > 
> > On Thu, May 31, 2012 at 5:19 PM, Rodrigo Rosenfeld Rosas
<rr.rosas@gmail.com (mailto:rr.rosas@gmail.com)> wrote:
> > > Em 31-05-2012 17 (tel:31-05-2012%2017):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. 
> > > 
> > > 
> > > > 
> > > > 
> > > > On Thursday, May 31, 2012 at 9:10 AM, Rodrigo Rosenfeld
Rosas 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.
> > > > > 
> > > > > 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.
> > > > > 
> 
> -- 
> 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
(mailto:rubyonrails-core@googlegroups.com).
> To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
(mailto:rubyonrails-core+unsubscribe@googlegroups.com).
> 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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

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.
On Thursday, 31 May 2012 09:10:28 UTC-4, Rodrigo Rosenfeld Rosas
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. 
>
> 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. 
>
>
On Thursday, 31 May 2012 09:10:28 UTC-4, Rodrigo Rosenfeld Rosas
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. 
>
> 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. 
>
>
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/rubyonrails-core/-/JcRpOEVShYwJ.
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.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

On 31 May 2012 14:10, Rodrigo Rosenfeld Rosas <rr.rosas@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

>
> 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.
>
> --
> 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<rubyonrails-core@googlegroups.com>
> .
> To unsubscribe from this group, send email to
>
rubyonrails-core+unsubscribe@**googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at http://groups.google.com/**
>
group/rubyonrails-core?hl=en<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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

> 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


On Friday, June 1, 2012 at 11:55 AM, Jeremy Walker wrote:
> 
> 
> On 31 May 2012 14:10, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com
(mailto:rr.rosas@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
>  
> > 
> > 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.
> > 
> > -- 
> > 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
(mailto:rubyonrails-core@googlegroups.com).
> > To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
(mailto:rubyonrails-core%2Bunsubscribe@googlegroups.com).
> > 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 rubyonrails-core@googlegroups.com
(mailto:rubyonrails-core@googlegroups.com).
> To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
(mailto:rubyonrails-core+unsubscribe@googlegroups.com).
> 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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

On 1 June 2012 17:10, Steve Schwartz <steve@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? :)

>
>
> -- Steve Schwartz
>
> On Friday, June 1, 2012 at 11:55 AM, Jeremy Walker wrote:
>
>
>
> On 31 May 2012 14:10, Rodrigo Rosenfeld Rosas <rr.rosas@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
>
>
>
> 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.
>
> --
> 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<rubyonrails-core@googlegroups.com>
> .
> To unsubscribe from this group, send email to
>
rubyonrails-core+unsubscribe@**googlegroups.com<rubyonrails-core%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at http://groups.google.com/**
>
group/rubyonrails-core?hl=en<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 rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to
> rubyonrails-core+unsubscribe@googlegroups.com.
> 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 rubyonrails-core@googlegroups.com.
> To unsubscribe from this group, send email to
> rubyonrails-core+unsubscribe@googlegroups.com.
> 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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

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.
> On Friday, June 1, 2012 at 11:55 AM, Jeremy Walker wrote:
>
>>
>>
>> On 31 May 2012 14:10, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com 
>> <mailto:rr.rosas@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
>>>
>>> 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.
-- 
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.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

Em 01-06-2012 13:20, Jeremy Walker escreveu:
>
>
> On 1 June 2012 17:10, Steve Schwartz <steve@alfajango.com 
> <mailto:steve@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 <http://project.id>)
>
> ...could be pre-processed, using a lookup in routes.rb, into:
> $.get "projects/#{project.id <http://project.id>}"
>
> ...which then gets compiled to:
> $.get "projects/" + project.id <http://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...

-- 
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.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

On 1 June 2012 17:22, Rodrigo Rosenfeld Rosas <rr.rosas@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.

-- 
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.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

> > > > 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 (http://project.id))
> > 
> > ...could be pre-processed, using a lookup in routes.rb, into:
> > $.get "projects/#{project.id (http://project.id)}"
> > 
> > ...which then gets compiled to:$.get "projects/" +
project.id (http://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


On Friday, June 1, 2012 at 12:22 PM, Rodrigo Rosenfeld Rosas wrote:
> Em 01-06-2012 13:20, Jeremy Walker escreveu: 
> > 
> > 
> > On 1 June 2012 17:10, Steve Schwartz <steve@alfajango.com
(mailto:steve@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 (http://project.id))
> > 
> > ...could be pre-processed, using a lookup in routes.rb, into: 
> > $.get "projects/#{project.id (http://project.id)}"
> > 
> > ...which then gets compiled to: $.get "projects/" +
project.id (http://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...
> -- 
> 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
(mailto:rubyonrails-core@googlegroups.com).
> To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
(mailto:rubyonrails-core+unsubscribe@googlegroups.com).
> 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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

Em 01-06-2012 13:45, Jeremy Walker escreveu:
>
>
> On 1 June 2012 17:22, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com 
> <mailto:rr.rosas@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 <http://project.id>)
>>
>>     ...could be pre-processed, using a lookup in routes.rb, into:
>>     $.get "projects/#{project.id <http://project.id>}"
>>
>>     ...which then gets compiled to:
>>     $.get "projects/" + project.id <http://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.
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?

-- 
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.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

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

-- 
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.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

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 <http://project.id>)
>>>
>>> ...could be pre-processed, using a lookup in routes.rb, into:
>>> $.get "projects/#{project.id <http://project.id>}"
>>>
>>> ...which then gets compiled to:
>>> $.get "projects/" + project.id <http://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.

-- 
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.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

Em 01-06-2012 14:42, Jeremy Walker escreveu:
>
>
> On 1 June 2012 18:23, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com 
> <mailto:rr.rosas@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...

-- 
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.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

On 1 Jun 2012, at 18:58, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com>
wrote:
> Em 01-06-2012 14:42, Jeremy Walker escreveu:
>> 
>> 
>> 
>> On 1 June 2012 18:23, Rodrigo Rosenfeld Rosas
<rr.rosas@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...
> -- 
> 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.
> 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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

Em 01-06-2012 15:20, Jeremy Walker escreveu:
>
>
> On 1 Jun 2012, at 18:58, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com 
> <mailto:rr.rosas@gmail.com>> wrote:
>
>> Em 01-06-2012 14:42, Jeremy Walker escreveu:
>>>
>>>
>>> On 1 June 2012 18:23, Rodrigo Rosenfeld Rosas
<rr.rosas@gmail.com
>>> <mailto:rr.rosas@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.

-- 
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.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

>
>
> 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 :)

-- 
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.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

Em 06-06-2012 12:25, Jeremy Walker escreveu:
>
>
>     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 :)
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.

-- 
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.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.