We’re closing in on the release of the Rails 3 beta. At the moment, we’re focusing on finalizing a number of APIs, including the new Railtie API, generators, the bundler, the new notification system, and a few more things. In all of these cases, the core code has been written, and we’re seeing how it feels to use the APIs in real plugins and applications, tweaking as we go.
In short, we’re pretty close to releasing a beta. We’d like the beta to be our best-attempt at feature/API complete, with the explicit acknowledgement that once a lot more people start working with the code, gaps and errors will need to be corrected.
If you’re aware of any gaps or errors that exist today in areas like ActionController, ActiveModel, or ActiveRecord, please let us know so we can make sure to get them corrected before the release. Feel free to take a look at the work going into Railties as well, but be aware that it’s still undergoing rapid API refinement, and most obvious gaps are on the short list to resolve before the beta.
So… if you have any patches for master, now’s the time!
Now we just need the community to write some good blog posts on how to
use all the new APIs
I'm playing with Rails 3pre now, but running into some roadblocks on
the way...
There are a number of areas in ActiveModel where assumptions are made
that your attributes exist via methods, I have briefly discussed this
with José Valim. There needs to be another hook method like
read_attribute_for_validation for the dirty module and a few other
places. I am happy to go ahead with this if required, I believe the
before_type_cast stuff assumes methods too.
I'd also like to wrap up a patch re-enabling streaming params parsing.
I have it started (http://gist.github.com/281693) and am in the
process of figuring out how to write the tests - given we need to
ensure the backends work when parsing from a Rack-compatible IO
object. Josh set me off in the right direction so I expect to be done
soon.
Also, I've had a ticket open for a while to officially get the yajl-
ruby backend in Rails core as one of the supported JSON decoding
backends. I can supply a patch for that soon as well. Fwiw, my fork of
technoweenie's yajl-rails plugin (enabling it as a backend) is up to
date as of rails 2.3.5 and from what I can tell in the code in Rails 3
it may be compatible with it as well. http://github.com/brianmario/yajl-rails.
The link to the yajl-ruby ticket is:
#2666 yajl-ruby as a JSON parsing backend - Ruby on Rails - rails
Forgot to mention I'd also like to try and find a creative way to not
have to forcefully require the JSON gem (activesupport/lib/
active_support/json/encoding.rb:13) even if the coder never intends on
using it.
Any chances to include the :full_message option to validators like the patched I've submited to this list some time ago? If yes, I'll prepare the tests and update documentation.
Any chances to include the :full_message option to validators like the
patched I've submited to this list some time ago? If yes, I'll prepare the
tests and update documentation.
Any chances to include the :full_message option to validators like the
patched I've submited to this list some time ago? If yes, I'll prepare the
tests and update documentation.
Apparently validation error message i18n in ActiveModel master is not backwards compatible with ActiveRecord 2.3.5. AR has seen a bunch of changes [1] between 2.3.2 and 2.3.3 (iirc) which haven't been ported to AM.
José, Mateo and me have discussed this offlist and want to ask for other opinions.
On the one hand this breaks backwards compatibility and reintroduces problems with error message i18n that already were solved. On the other hand the solution was suboptimal anyway because we had to maintain backwards compatibility in 2.3.x ("bugfix" releases).
I guess we need a decision between
a) maintaining BC to AR 2.3.5 vs BC to AM 2.3.5 and
b) maintaining BC vs releasing Rails 3 beta soon.
I'm personally cool with any of these options but I feel the decision has to be made or guided by rails core.
[1] The changes we're talking about were related to what we've called "lazy translation" of error messages. I.e. previously validation error messages were translated when they were added to AR::Errors. We've changed this so they just were collected and only translated when they were accessed. This then allowed to treat messages and full_messages in the same way and stuff like that.
Here's a run down of the issues with porting the AR 2.3.5 validation code to rails 3, for those who are curious about what the problem is:
in pre 3.0 versions of AR, all validation errors are kept in a single array, which is wrapped by the AR::Errors object; in 2.3.3 these were changed from strings to Error objects, but it didn't change the API because the user didn't have direct access to the array of errors, and the errors were converted to strings before being returned to the user.
in 3.0, validation errors are kept in multiple arrays, one per attribute, and these are passed directly to the user for manipulation. This allows the syntax errors[:attribute] << "message", but causes some issues with porting the Error object, since the error arrays will then contain a mix of strings and Error objects. Clearly this is not optimal for the end user, and alternative is the wrap those arrays in objects that will take care of converting from objects to strings and vice versa. However, having that wrapper duplicate all of Array's functionality will take a lot of code (a simple subset would be better), and having errors[:attribute] return something other than an array breaks a LOT of tests.
To sum up, it's not possible to port the lazy translation functionality to AM 3.0 without changing the API, and as sven said that's a decision that needs to be guided by rails core.
We've discussed this over at rails-i18n a bit more and our thinking is that probably nobody wants to delay Rails 3 beta because of this issue.
So our current thinking is that we want to
A - provide a good-old monkey-patching plugin. This would give us the opportunity to implement a clean-slate solution that does what we believe is right. We could get it battletested in plugin-land and put it out for discussion before including anything half-baked into Rails.
But this solution would obviously break expected behavior for some users who rely on what's been in AR since 2.3.3.
The two alternative solutions are:
B - port last summer's AR changes to Rails 3 AMo (would break AMo api though, see Mateos last mail)
C - try to implement a clean solution quickly enough to get it into Rails 3 beta
Personally I prefer option A because it's the most defensive one, but I still think it's a decision that should be guided by Rails core and we haven't gotten any feedback so far.
I'd like to understand better this problem. What would you like to achieve for Rails 3 (or 3.1) at all?
I think that a :full_message option would suffice for finishing the validation error messages limitation. Additionally it would be necessary to store the options passed to validations too so that these values would be available to error messages.
With a :full_message option, it would be possible to specify a symbol that could translate to anything you can imagine.
I'm playing with Rails 3pre now, but running into some roadblocks on
the way...