Rails 3 validation error messages

Rails Rails I18n
1

[José, Mateo, I’ll move this to the list]

Ok, so we’ve had this short non-discussion on rails-core :slight_smile:

It seems that Rails 3 validation error messages will be back to the
state of pre 2.3.3 at least for a short period of time. Unfortunately
nobody from rails core seems to back any of the decision options up so
the decision to break AR full_messages etc might “just happen” and we’ll
get some extra fire over here.

On the other hand this gives us the opportunity to start over with a
clean solution from scratch, implement it and get it hammered in
plugin-land and only move it to Rails after we know what we’re doing.

I’ve thus started to draft my ideas about this in code:

http://github.com/svenfuchs/messages_proposal

I’ve tried to separate all debatable “features” into optional modules.
That doesn’t mean these absolutely must be optional in Rails in the end
(even though I’d think it would be a good idea).

Enjoy and let me know what you think!

Here’s a copy of the readme:

Proposal: validation error messages in ActiveModel

This stuff is a very rough draft of how I propose to deal with
validation
error messages (and potentially other usecases that need I18n support,
such as
form labels).

It might go into Rails or end up in some plugin or gem.

I’m not looking so much at the actual integration to ActiveModel, yet.
So far
I’m just trying to sketch out the underlying stuff so that it covers all
requirements in a consistent way.

I want this stuff to be re-usable in other places where similar patterns
occur
when it comes to I18n, such as form labels and potentially other stuff.

Requirements:

  • Strings in class method calls should be treated as plain text by
    default
    (might optionally want to treat them as translation keys for
    gettext-style
    class method calls if requested by the user).
  • Symbols in class method calls should be treated as translation keys.
  • Use values from class method calls consistently with translation keys
    that
    are implicitly built for a validation.
  • Different translation variants (such as :full_message) for the same
    message
    should be possible.
  • Translation calls should optionally be able to cascade over scopes if
    requested by the user.
  • Support format strings, e.g. “{{attribute}} {{message}}”

See the tests, especially active_model_test.rb

2

[José, Mateo, I’ll move this to the list]

Ok, so we’ve had this short non-discussion on rails-core :slight_smile:

Yeah, I was a bit afraid that would happen

It seems that Rails 3 validation error messages will be back to the
state of pre 2.3.3 at least for a short period of time.
Unfortunately nobody from rails core seems to back any of the
decision options up so the decision to break AR full_messages etc
might “just happen” and we’ll get some extra fire over here.

Well, as I mentioned in my message to the rails core list, we can get
the lazy translation functionality back by having errors[:attribute]
return an array-like object rather than an array. The 2 consequences
of this are:

a) Reproducing all the functionality of an array will take a lot of
code, but then I don’t believe it’s actually necessary to implement
full array functionality; as long as it’s easy to add errors and the
object is enumerable, I think it will suffice for most peoples needs.
(i.e. is it really useful to be able to pack or zip the error array?)

b) Not returning arrays will break lots of tests; not a big deal
considering some of the other major changes being rolled out in 3.0,
but I felt I bit uncomfortable submitting a patch like that so I
wanted some feedback first.

Rails in the end (even though I’d think it would be a good idea).
I like where you’re going with this, and it would work well with the
change I’m proposing above, which would take care of the active model
integration. How would you propose we collaborate on this? I can push
my work to my rails fork, but that might not be the easiest for others
to run it?

3

On Jan 26, 2010, at 4:02 AM, Mateo Murphy wrote:

Ok, so we’ve had this short non-discussion on rails-core :slight_smile:
Yeah, I was a bit afraid that would happen

I guess we have to raise more attention. In any case we’re breaking some
behavior that people do expect.

Well, as I mentioned in my message to the rails core list, we can get the lazy translation functionality back by having errors[:attribute] return an array-like object rather than an array. The 2 consequences of this are:

a) Reproducing all the functionality of an array will take a lot of code, but then I don’t believe it’s actually necessary to implement full array functionality; as long as it’s easy to add errors and the object is enumerable, I think it will suffice for most peoples needs. (i.e. is it really useful to be able to pack or zip the error array?)

I agree. We’d probably want to implement at least as much as is tested
in the test suite.

b) Not returning arrays will break lots of tests; not a big deal considering some of the other major changes being rolled out in 3.0, but I felt I bit uncomfortable submitting a patch like that so I wanted some feedback first.

I think in the long run this aspect of AM (returning a plain Array) must
go away anyway. Arrays are too stupid for what we need.

I like where you’re going with this, and it would work well with the change I’m proposing above, which would take care of the active model integration. How would you propose we collaborate on this? I can push my work to my rails fork, but that might not be the easiest for others to run it?

What about aiming for a plugin for now. I’d add you as a collaborator
and we work a monkey-patch’ing plugin out over there.

I believe a plugin would be the best option right now. We haven’t heard
back from Rails core, yet, so this is just me guessing wildly but I
would bet that they don’t want to delay Rails 3 beta because of this
stuff. Plus, we’d have to implement it (and meet the expectation to “do
the right thing”, resolve all potential discussions etc.) really
quickly. So instead we could try to get a plugin ready when Rails 3 beta
comes out and ask people to use it and help us when they want “fancy”
I18n error messages. Then we could aim for pushing it back to Rails for
3.1 or something.

This way we could both back up Rails core re releasing Rails 3 soon and
have the freedom to experiment with a good solution.

Wdyt?

4

sounds good :slight_smile:
IMHO it’s good idea.

2010/1/26 Sven F. [email protected]

considering some of the other major changes being rolled out in 3.0, but I
it?
it and help us when they want “fancy” I18n error messages. Then we could aim
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected][email protected]
.
For more options, visit this group at
http://groups.google.com/group/rails-i18n?hl=en.

–
Experiencia es lo que obtienes, cuando no obtienes lo que quieres.

5

On Jan 27, 2010, at 5:02 AM, Mateo Murphy wrote:

I agree. We’d probably want to implement at least as much as is tested in the test suite.
A quick scan reveals:

<<
any?
empty?
include?
first

most of which is provided by enumerable anyway.

Ah, interesting.

The << method brings up a question I had regarding what you’ve started working on: in your Message class there’s both a type and a message attribute; how do you propose we populate these when the user passes a short message like errors[:name] << “not valid”?

I think I might be able to factor type out.

It’s currently populated with the default validation key (e.g. :blank
for validates_presence_of) and will only be used if message is nil (in
Translated,
http://github.com/svenfuchs/messages_proposal/blob/master/lib/message/translated.rb#L16)

I see errors[:name] << “not valid” as equivalent to specifying a String
as a message on class-level as in

validates_presence_of :foo, :message => ‘not valid’

So, errors[:name] << “not valid” would generate Message.new(nil, “not
valid”) and always evaluate to “not valid”

If users want this to be translated the would need to do errors[:name]
<< :not_valid

Does that make sense?

That sounds good to me. It’s a bit unfortunate that people will have to deal with an api change with 3.0, and potentially another in 3.1, but getting the word out about the plugin quickly should help mitigate that

Ok, I’ve added you to the repo at:
http://github.com/svenfuchs/messages_proposal

I’ve been working on the library code a bit more and I believe it should
be usable as a base line for the plugin.

How do you think we could best collaborate? Maybe meet in
irc.freenode.net#rails-i18n?

6

On 27-Jan-10, at 8:45 AM, Sven F. wrote:

Does that make sense?

Yes it does, but just to throw this out there, what about using a
subclass of error rather than a type? Treat it something like an
Exception?

How do you think we could best collaborate? Maybe meet in
irc.freenode.net#rails-i18n?

Sure, given the timezone difference though, unless you’re willing to
meet late at night, it’ll have to be during the weekend…

7

On Jan 28, 2010, at 5:24 PM, Mateo Murphy wrote:

If users want this to be translated the would need to do errors[:name] << :not_valid

Does that make sense?

Yes it does, but just to throw this out there, what about using a subclass of error rather than a type? Treat it something like an Exception?

I’ve now entirely removed this argument. Clients (i.e. #generate_message
in this case) can just default message || type themselves.

Sure, given the timezone difference though, unless you’re willing to meet late at night, it’ll have to be during the weekend…

Ok, fine. Just give me a ping :slight_smile:

8

On 26-Jan-10, at 7:21 AM, Sven F. wrote:

error array?)

I agree. We’d probably want to implement at least as much as is
tested in the test suite.

A quick scan reveals:

<<
any?
empty?
include?
first

most of which is provided by enumerable anyway.

The << method brings up a question I had regarding what you’ve started
working on: in your Message class there’s both a type and a message
attribute; how do you propose we populate these when the user passes a
short message like errors[:name] << “not valid”?

and help us when they want “fancy” I18n error messages. Then we
could aim for pushing it back to Rails for 3.1 or something.

This way we could both back up Rails core re releasing Rails 3 soon
and have the freedom to experiment with a good solution.

Wdyt?

That sounds good to me. It’s a bit unfortunate that people will have
to deal with an api change with 3.0, and potentially another in 3.1,
but getting the word out about the plugin quickly should help mitigate
that