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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
