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! Yehuda Katz Developer | Engine Yard (ph) 718.877.1325 -- 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.
Really great work!!! 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.
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! > > Yehuda Katz > Developer | Engine Yard > (ph) 718.877.1325-- 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 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-as-a-json-parsing-backend -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! > > > Yehuda Katz > > Developer | Engine Yard > > (ph) 718.877.1325-- 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.
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! > > > > Yehuda Katz > > > Developer | Engine Yard > > > (ph) 718.877.1325-- 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. 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! > > Yehuda Katz > Developer | Engine Yard > (ph) 718.877.1325 >-- 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.> > 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! >> >> Yehuda Katz >> Developer | Engine Yard >> (ph) 718.877.1325 >> > > > -- > 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. > > > >-- Paul Campbell paul@rushedsunlight.com - - - - - - - - - - - - - - - - - - - blog http://www.pabcas.com twitter http://www.twitter.com/paulca github http://www.github.com/paulca phone +353 87 914 8162 - - - - - - - - - - - - - - - - - - - -- 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/20/10 9:58 PM, Paul Campbell 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. > > 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! >>> >>> Yehuda Katz >>> Developer | Engine Yard >>> (ph) 718.877.1325 >>> >> >> >> -- >> 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.
Is there a solution for https://rails.lighthouseapp.com/projects/16213/tickets/112-undefined-method-alias_method_chain-for-cgiclass-when-generating-guidesin 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. 2010/1/21 Ben Munat <bmunat@gmail.com>> On 1/20/10 9:58 PM, Paul Campbell 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. >>> >> >> 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! >>>> >>>> Yehuda Katz >>>> Developer | Engine Yard >>>> (ph) 718.877.1325 >>>> >>>> >>> >>> -- >>> 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%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. > 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. > > >-- 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. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
There are quite a few patches in Lighthouse that are not yet applied to patch. What about them? Though some of them don''t apply to master cleanly, but we can certainly remake the patch. On Thu, Jan 21, 2010 at 10:04 AM, Ryan Bigg <radarlistener@gmail.com> wrote:> Is there a solution for > https://rails.lighthouseapp.com/projects/16213/tickets/112-undefined-method-alias_method_chain-for-cgiclass-when-generating-guidesin 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. > > 2010/1/21 Ben Munat <bmunat@gmail.com> > > On 1/20/10 9:58 PM, Paul Campbell 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. >>>> >>> >>> 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! >>>>> >>>>> Yehuda Katz >>>>> Developer | Engine Yard >>>>> (ph) 718.877.1325 >>>>> >>>>> >>>> >>>> -- >>>> 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%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. >> 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. >> >> >> > > > -- > 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%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. 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! > > > Yehuda Katz > > Developer | Engine Yard > > (ph) 718.877.1325-- 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.
Sven Fuchs
2010-Jan-21 12:11 UTC
Re: Closing in on Last Call for the Beta (validation error message i18n)
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.
On Jan 20, 2010, at 10:59 AM, Yehuda Katz 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!
>
> Yehuda Katz
> Developer | Engine Yard
> (ph) 718.877.1325
>
> --
> 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.
Is there a general list of features somewhere that made it into the 3.0 cut so far? On Thu, Jan 21, 2010 at 4:06 AM, José Valim <jose.valim@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! > > > > > Yehuda Katz > > > Developer | Engine Yard > > > (ph) 718.877.1325 > > -- > 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%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. 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.
Mateo Murphy
2010-Jan-21 19:41 UTC
Re: Closing in on Last Call for the Beta (validation error message i18n)
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.
On it ;) http://github.com/radar/rails Ryan Bigg On 20/01/2010, at 20:59, Kristian Mandrup <kmandrup@gmail.com> wrote:> Really great work!!! > > 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 > . > >-- 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.
Rodrigo Rosenfeld Rosas
2010-Jan-21 20:20 UTC
Re: Re: Closing in on Last Call for the Beta
Done: https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/3768-patch-add-full_message-option-to-validations Thanks, Rodrigo. Em 21-01-2010 07:06, José Valim escreveu:> 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! >>> >> >>> Yehuda Katz >>> Developer | Engine Yard >>> (ph) 718.877.1325 >>>-- 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.
is rails 3 going to support field-level-security? thx -- 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.
What''s the status of the queuing abstraction layer? I remember hearing about it a while back, but I don''t see anything about it in master. Is it dead? On Jan 21, 12:34 pm, tom <tomabr...@gmail.com> wrote:> is rails 3 going to support field-level-security? > thx-- 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.
Sven Fuchs
2010-Jan-27 17:30 UTC
Re: Closing in on Last Call for the Beta (validation error message i18n)
*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. > >-- 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.
Rodrigo Rosenfeld Rosas
2010-Jan-28 12:50 UTC
Re: Closing in on Last Call for the Beta (validation error message i18n)
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.
validates_numericallity_of :age, :greater_than_or_equal_to => 21,
:less_than_or_equal_to => 100, :full_message =>
:''my_model.age_range_error_message''
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.
Sven Fuchs
2010-Jan-28 13:22 UTC
Re: Closing in on Last Call for the Beta (validation error message i18n)
Hi Rodrigo, 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? Btw this is a rough draft of how I''d propose to solve the issues: http://github.com/svenfuchs/messages_proposal 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. > > validates_numericallity_of :age, :greater_than_or_equal_to => 21, :less_than_or_equal_to => 100, :full_message => :''my_model.age_range_error_message'' > > 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. >-- 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.
Rodrigo Rosenfeld Rosas
2010-Jan-28 14:54 UTC
Re: Closing in on Last Call for the Beta (validation error message i18n)
Hi Sven,
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:
http://yehudakatz.com/2010/01/10/activemodel-make-any-ruby-object-feel-like-activerecord/
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.
Best Regards,
Rodrigo.
Em 28-01-2010 11:22, Sven Fuchs escreveu:> Hi Rodrigo,
>
> 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?
>
> Btw this is a rough draft of how I''d propose to solve the issues:
http://github.com/svenfuchs/messages_proposal
>
>
> 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.
>>
>> validates_numericallity_of :age, :greater_than_or_equal_to => 21,
:less_than_or_equal_to => 100, :full_message =>
:''my_model.age_range_error_message''
>>
>> 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.