Re: [Rails-core] Approximate release timeline for Rails 4?
On 1 October 2012 00:43, Steve Klabnik st...@steveklabnik.com wrote: Soonish. There are some things that are blocking the release, but they're being worked on. There's no set date. All the major pieces are in place. am curious if it would be better to split the bugs out as individual issues (happens sooner) or fix them in a bigger patch (takes longer). Always split them up into the smallest possible things. Makes them easier to review, makes them easier to write, makes it easy to pick and choose between portions. Talking of patches, is there any chance that someone could look at PR #6450 please. It's to do with routing. It's over 4 months old but I rebased it yesterday. If anyone has a couple of free minutes, could they pull it or let me know what needs changing please? https://github.com/rails/rails/pull/6450/ Thanks, guys. -- 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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Route helpers in JS/CS assets
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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Route helpers in JS/CS assets
On 31 May 2012 14:10, Rodrigo Rosenfeld Rosas rr.ro...@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.**comrubyonrails-core@googlegroups.com
.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@**googlegroups.comrubyonrails-core%2bunsubscr...@googlegroups.com
.
For more options, visit this group at http://groups.google.com/**
group/rubyonrails-core?hl=enhttp://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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Route helpers in JS/CS assets
On 1 June 2012 17:10, Steve Schwartz st...@alfajango.com wrote:
tl;dr;
Hook into routes.rb while compiling CoffeeScript to Javascript and enable
native feeling routes in CoffeeScript.
I think the problem there is that you wouldn't know to put 1 in there at
asset compile time. It'd only work for un-nested collection paths like
/products.
But in the CoffeeScript, the developer will know the id of the resource
they're calling.
So, the CS:
$.get project_path(project.id)
...could be pre-processed, using a lookup in routes.rb, into:
$.get projects/#{project.id}
...which then gets compiled to:
$.get projects/ + project.id
And voila, you have a working solution. Am I missing something? :)
-- Steve Schwartz
On Friday, June 1, 2012 at 11:55 AM, Jeremy Walker wrote:
On 31 May 2012 14:10, Rodrigo Rosenfeld Rosas rr.ro...@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.**comrubyonrails-core@googlegroups.com
.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@**googlegroups.comrubyonrails-core%2bunsubscr...@googlegroups.com
.
For more options, visit this group at http://groups.google.com/**
group/rubyonrails-core?hl=enhttp://groups.google.com/group/rubyonrails-core?hl=en
Re: [Rails-core] Route helpers in JS/CS assets
On 1 June 2012 17:22, Rodrigo Rosenfeld Rosas rr.ro...@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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Route helpers in JS/CS assets
On 1 June 2012 18:23, Rodrigo Rosenfeld Rosas rr.ro...@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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
Re: [Rails-core] Attribute query methods and semantics
On 31 May 2012 14:23, Sam Oliver s...@samoliver.com wrote: On Thu, May 31, 2012 at 2:12 PM, James B. Byrne byrn...@harte-lyne.cawrote: I would generate attribute query methods only for boolean attributes. I am not sure that I understand your point, but in Ruby anything that is neither nil nor false is true. Thus returning the url string, if not nil, is the same as saying that it is true but also allows access to the actual data without having to send another message. I think Max's point is that post.visible? could be read as post is visible? but post is url? carries a different meaning. Maybe have query methods for boolean attributes and prefixed query methods for not. e.g. post.visible? post.has_url? Or maybe leave the currently methods as they are, but add new prefixed methods, with different prefixes for boolean methods, e.g. post.is_visible? post.has_url? Sam -- 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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
