Closing in on Last Call for the Beta

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

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:

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.