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!
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.
Kind regards,
Jamie
On Jan 20, 9:59 am, Yehuda Katz <wyc...@gmail.com> wrote:
> 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!
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: https://rails.lighthouseapp.com/projects/8994/tickets/2666-yajl-ruby-...
-Brian
On Jan 20, 4:54 am, thelucid <ja...@soniciq.com> wrote:
> 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.
> Kind regards,
> Jamie
> On Jan 20, 9:59 am, Yehuda Katz <wyc...@gmail.com> wrote:
> > Hey everyone,
> > 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!
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.
-Brian
On Jan 20, 9:34 am, brianmario <seniorlo...@gmail.com> wrote:
> 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:https://rails.lighthouseapp.com/projects/8994/tickets/2666-yajl-ruby-...
> -Brian
> On Jan 20, 4:54 am, thelucid <ja...@soniciq.com> wrote:
> > Hi Yehuda,
> > Great news.
> > 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.
> > Kind regards,
> > Jamie
> > On Jan 20, 9:59 am, Yehuda Katz <wyc...@gmail.com> wrote:
> > > Hey everyone,
> > > 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!
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.
> 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!
> 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.
>> 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!
> -- > 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.
>> 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.
>>> 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!
>> -- >> 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.
>> 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.
>> Would love to see this make it in.
> +1
>>> Rodrigo.
>>> Em 20-01-2010 07:59, Yehuda Katz escreveu:
>>>> Hey everyone,
>>>> 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!
>>> -- >>> 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<rubyonrails-core%2Bunsubscrib e@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<rubyonrails-core%2Bunsubscrib e@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en.
> 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.
> Rodrigo.
> Em 20-01-2010 07:59, Yehuda Katz escreveu:
> > Hey everyone,
> > 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!
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.
> 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!
> -- > 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 Thu, Jan 21, 2010 at 4:06 AM, José Valim <jose.va...@gmail.com> wrote: > Please attach a patch on Lighthouse and assign it to me.
> On Jan 21, 12:22 am, Rodrigo Rosenfeld Rosas <rr.ro...@gmail.com> > wrote: > > 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.
> > Rodrigo.
> > Em 20-01-2010 07:59, Yehuda Katz escreveu:
> > > Hey everyone,
> > > 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!
> -- > 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<rubyonrails-core%2Bunsubscrib e@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en.
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...
On Thu, Jan 21, 2010 at 10:04 AM, Ryan Bigg <radarliste...@gmail.com> wrote: > Is there a solution for > https://rails.lighthouseapp.com/projects/16213/tickets/112-undefined-... the works? I've also got this in another (non-guide related) circumstance > which I can't recall right now. It's coming from using 1.8.7 as far as I can > tell.
>>> 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.
>>> Would love to see this make it in.
>> +1
>>>> Rodrigo.
>>>> Em 20-01-2010 07:59, Yehuda Katz escreveu:
>>>>> Hey everyone,
>>>>> 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!
>>>> -- >>>> 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<rubyonrails-core%2Bunsubscrib e@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<rubyonrails-core%2Bunsubscrib e@googlegroups.com> >> . >> For more options, visit this group at >> http://groups.google.com/group/rubyonrails-core?hl=en.
> -- > Ryan Bigg
> -- > 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<rubyonrails-core%2Bunsubscrib e@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en.
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.
> 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.
> 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... > -- > 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 > .
> Please attach a patch on Lighthouse and assign it to me.
> On Jan 21, 12:22 am, Rodrigo Rosenfeld Rosas<rr.ro...@gmail.com> > wrote:
>> 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.
>> Rodrigo.
>> Em 20-01-2010 07:59, Yehuda Katz escreveu:
>>> Hey everyone,
>>> 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!
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.
> 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.
> On 21-Jan-10, at 7:11 AM, Sven Fuchs wrote:
>> 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.
> -- > 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'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.
> 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.
> On Jan 21, 2010, at 8:41 PM, Mateo Murphy wrote:
>> 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.
>> On 21-Jan-10, at 7:11 AM, Sven Fuchs wrote:
>>> 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.
the current AMo validations code has a couple of problems regarding I18n that basically all are related to the fact that messages are generated "early" (i.e. in the moment when they are added to the errors collection) and features (like full messages, message formats etc.) have been implemented on top of this. (This has lead to the rather weird implementation last summer that had to maintain BC.)
I can see how your proposal would solve some of the usecases and I'm not against applying it. I don't think it solves the root problem though.
Even with your proposal messages would always get translated first, right? You'd store the translation key and options so that you can look full messages up later. That means that even though users might only want the full message the I18n backend would be hit twice because the short message is always looked up, too. This might not be a huge problem but it illustrates why we believe that messages should not be resolved early.
Why not go back to the drawing board for a few months, implement our ideas as plugins, get everything sorted and then patch AMo afterwards?
> 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.
> en.yml > en: > my_model: > age_range_error_message: You must specify an age between {{greater_than_or_equal_to}} and {{less_than_or_equal_to}}.
> Wouldn't this approach solve most I18n complications?
> Best regards,
> Rodrigo.
> Em 27-01-2010 15:30, Sven Fuchs escreveu: >> *bump*
>> Can we get some input on this from 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.
>> On Jan 21, 2010, at 8:41 PM, Mateo Murphy wrote:
>>> 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.
>>> On 21-Jan-10, at 7:11 AM, Sven Fuchs wrote:
>>>> 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.
> -- > 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 agree with you that delayed full messages would be better. My patch to include the :full_message option was not meant to solve ActiveModel's deficiency, but to achieve a result that would easy a lot of use cases in a fast way that could be scheduled for next Rails beta. The main goal was to define a new API for validators to include a new fundamental option (full_message). This is important because even if the implementation changes because the regular user API would be kept.
For instance, when Yehuda presented the ActiveModel API on his post, here is what is presented:
class PresenceValidator < EachValidator def validate(record) record.errors.add_on_blank(attributes, options[:message]) end end
This API would break if a :full_message parameter was added to validators. In my patch I changed "options[:message]" to "message" which is a method from a base validator class that gets the message from options.
That is why I'm so worried. I think it would be great to rewrite the validations messages part of ActiveModel but the time to define a better API is now. We can change the implementation later...
Being said that, I think we should really change the ActiveModel's message generation implementation to a better one. It is just a question of timing...
Basically, we should need to change Errors.add() API to include the parameters passed to the validators. With these parameters available from Errors it would open a new world of possibilities of what plugin writters would be able to do with error messages. If we include the parameters to Errors.add() we would not need to evaluate the messages soon. They could be lazy evaluated then...
I didn't change Errors.add() API on my patch because I was concerned on it being applyied soon (in Rails 3 beta, for instance). My first concern was to define a new feature to API that was backward compatible with existent plugins and previous Rails versions.
I'll take a look at the proposal you mentioned and I'll let you know what I think.
> the current AMo validations code has a couple of problems regarding I18n that basically all are related to the fact that messages are generated "early" (i.e. in the moment when they are added to the errors collection) and features (like full messages, message formats etc.) have been implemented on top of this. (This has lead to the rather weird implementation last summer that had to maintain BC.)
> I can see how your proposal would solve some of the usecases and I'm not against applying it. I don't think it solves the root problem though.
> Even with your proposal messages would always get translated first, right? You'd store the translation key and options so that you can look full messages up later. That means that even though users might only want the full message the I18n backend would be hit twice because the short message is always looked up, too. This might not be a huge problem but it illustrates why we believe that messages should not be resolved early.
> Why not go back to the drawing board for a few months, implement our ideas as plugins, get everything sorted and then patch AMo afterwards?
> On Jan 28, 2010, at 1:50 PM, Rodrigo Rosenfeld Rosas wrote:
>> Hi Sven, Mateo.
>> 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.
>> en.yml >> en: >> my_model: >> age_range_error_message: You must specify an age between {{greater_than_or_equal_to}} and {{less_than_or_equal_to}}.
>> Wouldn't this approach solve most I18n complications?
>> Best regards,
>> Rodrigo.
>> Em 27-01-2010 15:30, Sven Fuchs escreveu:
>>> *bump*
>>> Can we get some input on this from 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.
>>> On Jan 21, 2010, at 8:41 PM, Mateo Murphy wrote:
>>>> 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.
>>>> On 21-Jan-10, at 7:11 AM, Sven Fuchs wrote:
>>>>> 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.
