Closing in on Last Call for the Beta
Yehuda Katz
thelucid
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
brianmario
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
brianmario
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-...
Rodrigo Rosenfeld Rosas
patched I've submited to this list some time ago? If yes, I'll prepare
the tests and update documentation.
Rodrigo.
Paul Campbell
> 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 rubyonra...@googlegroups.com.
> To unsubscribe from this group, send email to
> rubyonrails-co...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/rubyonrails-core?hl=en.
>
>
>
>
--
Paul Campbell
pa...@rushedsunlight.com
- - - - - - - - - - - - - - - - - - -
blog http://www.pabcas.com
twitter http://www.twitter.com/paulca
github http://www.github.com/paulca
phone +353 87 914 8162
- - - - - - - - - - - - - - - - - - -
Ben Munat
>> 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
Ryan Bigg
--
Ryan Bigg
José Valim
On Jan 21, 12:22 am, Rodrigo Rosenfeld Rosas <rr.ro...@gmail.com>
wrote:
Sven Fuchs
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.
Stephen
Kristian Mandrup
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...
Rizwan Reza
Mateo Murphy
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.
Ryan Bigg
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-
> co...@googlegroups.com.
Rodrigo Rosenfeld Rosas
tom
thx
Chris Hanks
about it a while back, but I don't see anything about it in master. Is
it dead?
Sven Fuchs
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.
Rodrigo Rosenfeld Rosas
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.
Sven Fuchs
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
>>>> 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.
>>>>
>>>
>
Rodrigo Rosenfeld Rosas
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.
>>>>> Jos�, Mateo and me have discussed this offlist and want to ask for other opinions.