full_message option added to Rails validations

37 views
Skip to first unread message

Rodrigo Rosenfeld Rosas

unread,
Jan 2, 2010, 5:52:42 PM1/2/10
to Ruby on Rails: Core
I've done some experiment writing a patch to support a full_message
option on Rails validations, as can be seen here:

http://groups.google.com/group/rubyonrails-core/msg/5bf5c89330805373

I would like to finish the patch, writing the documentation and tests
and submit it to Lighthouse.

But I don't know how to proceed with documentation, since it is not very
DRY...

Should I send a description to appreciation and then copy and paste it
on every validation method?

If so, would the following description be ok?

"Configuration options:
* <tt>message</tt> - A custom error message (default is: "can't be
blank"). <tt>full_message</tt> can
be specified instead, in which case the humanized attribute name won't
be prepended to the message.
You have to choose between either <tt>message</tt> or
<tt>full_message</tt>, not both. If that happens,
<tt>full_message</tt> takes precedence.
..."

The only difference between validations would be the default...


Regarding test writing, I would also ask for some guidance on it.

I've noted that not all options are tested on each validation respective
test.

So, I would like to know if I should add a test on with_validations_test.rb,
add a new test file or add a new test for every validation class.

Please, how should I proceed?

Thanks in advance,

Rodrigo.

Mateo Murphy

unread,
Jan 2, 2010, 10:05:33 PM1/2/10
to rubyonra...@googlegroups.com
Hi Rodrigo,

As I was looking at your patch, I realized that some of the changes
made to validations in 2.3.4 haven't been moved over to activemodel
yet, and moving that code over would conflict with the code you're
changing. I've email Sven Fuchs (who worked on those changes) about
this, and I'm waiting to hear back from him on this, but you might
want to wait before continuing working on your patch. In the meantime,
you can check out the validation code in 2.3.4 to see what was changed
and how that would affect your patch.

Cheers,

mateo

> --
>
> 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.
> 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
> .
>
>

Rodrigo Rosenfeld Rosas

unread,
Jan 2, 2010, 10:28:25 PM1/2/10
to rubyonra...@googlegroups.com
Hi Mateo, I think that maybe it would be better to wait for Fuchs to
adapt his change to master before I rewrite the patch.

But, anyway, I will still need some help on how to modify the
documentation and how to write the tests...

I am waiting for Fuchs feedback before I continue... Until there, help
with documentation and tests are welcome! :)

Thanks,

Rodrigo.

Mateo Murphy escreveu:

Sven Fuchs

unread,
Jan 3, 2010, 7:11:03 AM1/3/10
to rubyonra...@googlegroups.com
Sorry for not answering earlier here, just back from a vacation.

Tbh I have no idea about the state of AM validations in master. I was thinking that José was working on it but maybe that's not true any more? In your email you said that you'd be willing to work on this. That would be perfectly fine with me, but maybe it's best to check back with José first, too.

Just to not leave this stone unturned though:

Meanwhile we've been discussing the idea to make the validation messages implementation pluggable in some way. There apparently are lots of edge cases (like various full_messages features) - none of which is relevant to most users, but all which still seem to be crucial for specific users. This basically is the same situation that we've solved with pluggable backends in I18n in general, just more focussed on a special feature.

So maybe for Rails 3 it would make sense to refactor towards a clear internal API to allow people to plug in a different implementation if the shipped default implementaiton does not fit their needs. (This could be something as simple as ActiveModel.errors_class = ActiveModel::Errors, which could be changed by users.) Again, the default implementation could just solve the most important features and leave everything else to plugin land for starters.

> To post to this group, send email to rubyonra...@googlegroups.com.

Rodrigo Rosenfeld Rosas

unread,
Jan 3, 2010, 8:17:53 AM1/3/10
to rubyonra...@googlegroups.com
Hi Sven, I hope you have had a great vacation!

I don't think that a full_message option would be a feature to be
explored by plugins only, for several reasons.

I18n different backend plugins make sense because some basic external
API are kept unchanged (I18n.translate/t) and we can test different
implementation without changing application source-code, with the
ability to store the translations in different means and benchmark
performance between several engines. That was an awesome job, but I
don't think this approach would fit in the case of an extra parameter to
validations.

I never understood why Rails never supported some way of specifying the
full message. This is what I would call "Convention over Configuration".
If you don't configure (specifying the message of full message) you only
have to specify the validation and the attribute and a default message
will be concatenated with the attribute in a default way. But it is
lacking a bit of the configuration part when the default convention does
not fit. It has the ability to override the message, but not for
override how to concatenate it with the field, or not concatenating it
at all.

And I don't think that only some users would benefit from this, but
almost every one will have some situation where a full message would fit
better than having to think about how to reformulate a phrase so that it
starts with the attribute name. Also, I don't think this should be
approached with I18n, since it is not an internationalization issue.

Rails is always recommended for agile development. Imagine the following
scene: you present your solution to your client and she loved it, but
has only a few adjustments.

She really care about UI and she feels that some error messages should
be a bit different and ask you to change them to something that she
would prefer that doesn't follow Rails concatenation convention. Then,
what would you do? "Sorry madam, but this is actually not that simple to
change and the code would become less maintainable if we do that. Would
you please reconsider keeping the phrase as it is?" I doubt she would
understand the reason why it is difficult to get full control about the
error messages...

I can see, though, reasons for having plugins to validations but for
other reasons. For instance, I believe many people would prefer the
error message to appear next to the field with problem instead of
showing all of them with a single error box. But this would require
modifying ActionPack helpers instead of ActiveModel...

I simple don't think that a full_message option would be an edge case.

Cheers,

Rodrigo.

Sven Fuchs escreveu:


> Sorry for not answering earlier here, just back from a vacation.
>

> Tbh I have no idea about the state of AM validations in master. I was thinking that Jos� was working on it but maybe that's not true any more? In your email you said that you'd be willing to work on this. That would be perfectly fine with me, but maybe it's best to check back with Jos� first, too.

Ben Munat

unread,
Jan 3, 2010, 5:15:41 PM1/3/10
to rubyonra...@googlegroups.com
It has long been one of my annoyances that Rails doesn't make it easier
to override the full error message for a validation. At my job, the
product manager routinely asks for a specific validation message.

It's great that Rails will use a sensible default message, but being
able to specify full message as an option on the validation declaration
would seem both very useful and not too hard to add.

Strong plus one here.

b

Sven Fuchs

unread,
Jan 3, 2010, 5:36:02 PM1/3/10
to rubyonra...@googlegroups.com
It's possible since (iirc) 2.3.3.

I have no idea why people keep repeating it's not possible. Maybe a documentation issue.
Tbh I have no idea about the state of AM validations in master. I was thinking that José was working on it but maybe that's not true any more? In your email you said that you'd be willing to work on this. That would be perfectly fine with me, but maybe it's best to check back with José first, too.

Ben Munat

unread,
Jan 3, 2010, 6:30:00 PM1/3/10
to rubyonra...@googlegroups.com
Really? I see no mention of "full" anything here:

http://api.rubyonrails.org/classes/ActiveRecord/Validations/ClassMethods.html

I tried a :full_message and :fullmessage option on a validation in a
model in a 2.3.4 project and a 2.3.5 project and both were ignored.
Googling for a means of suppressing the attribute name in the error
message has found me only blogs suggesting plugins or monkey-patching.

Are you talking about using the I18n stuff? I had never looked at that
(we don't do any I18n at my work), but it does look like the Errors
class looks up messages from translation files. Perhaps this allows
replacement of the full error message?

But even if so, that is not what Rodrigo and I are talking about. We
just want a simple :full_message option on all the validation helpers
that allows us to provide the entire error message without the attribute
name being inserted.

If that does exist in Rails 2.x.x somewhere I would really appreciate a
pointer.

Thanks,

Ben

>>>> was thinking that Jos� was working on it but maybe that's not true


>>>> any more? In your email you said that you'd be willing to work on
>>>> this. That would be perfectly fine with me, but maybe it's best to

>>>> check back with Jos� first, too.

>>> <mailto:rubyonra...@googlegroups.com>.


>>> To unsubscribe from this group, send email to
>>> rubyonrails-co...@googlegroups.com

>>> <mailto:rubyonrails-co...@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 rubyonra...@googlegroups.com

>> <mailto:rubyonra...@googlegroups.com>.


>> To unsubscribe from this group, send email to
>> rubyonrails-co...@googlegroups.com

>> <mailto:rubyonrails-co...@googlegroups.com>.

Ryan Bigg

unread,
Jan 3, 2010, 6:40:34 PM1/3/10
to rubyonra...@googlegroups.com
There's also the custom-err-msg plugin that allows this functionality by doing :message => "^The field was invalid" which does not prefix the message with the field name.

2010/1/4 Ben Munat <bmu...@gmail.com>
>>>> was thinking that José was working on it but maybe that's not true

>>>> any more? In your email you said that you'd be willing to work on
>>>> this. That would be perfectly fine with me, but maybe it's best to
>>>> check back with José first, too.



--
Ryan Bigg

George

unread,
Jan 3, 2010, 7:02:45 PM1/3/10
to rubyonra...@googlegroups.com
On Sun, Jan 3, 2010 at 6:30 PM, Ben Munat <bmu...@gmail.com> wrote:

If that does exist in Rails 2.x.x somewhere I would really appreciate a
pointer.


It's not on api.rubyonrails.org for some reason, but here's the rdoc for AR::Error#generate_full_message:

      # Wraps an error message into a full_message format.
      #
      # The default full_message format for any locale is <tt>"{{attribute}} {{message}}"</tt>.
      # One can specify locale specific default full_message format by storing it as a
      # translation for the key <tt>:"activerecord.errors.full_messages.format"</tt>.
      #
      # Additionally one can specify a validation specific error message format by
      # storing a translation for <tt>:"activerecord.errors.full_messages.[message_key]"</tt>.
      # E.g. the full_message format for any validation that uses :blank as a message
      # key (such as validates_presence_of) can be stored to <tt>:"activerecord.errors.full_messages.blank".</tt>
      #
      # Because the message key used by a validation can be overwritten on the
      # <tt>validates_*</tt> class macro level one can customize the full_message format for
      # any particular validation:
      #
      #   # app/models/article.rb
      #   class Article < ActiveRecord::Base
      #     validates_presence_of :title, :message => :"title.blank"
      #   end
      #
      #   # config/locales/en.yml
      #   en:
      #     activerecord:
      #       errors:
      #         full_messages:
      #           title:
      #             blank: This title is screwed!

George.

Ryan Bigg

unread,
Jan 3, 2010, 7:05:14 PM1/3/10
to rubyonra...@googlegroups.com
Probably a recent documentation, the API docs are not updated often.

2010/1/4 George <george...@gmail.com>

--

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.



--
Ryan Bigg

Ben Munat

unread,
Jan 3, 2010, 7:38:50 PM1/3/10
to rubyonra...@googlegroups.com
Yeah, that's the "I18n stuff" I mentioned in my reply to Sven, though
the rdoc that I found for generate_full_message was more cryptic and did
not mention that you can use the I18n capabilities to override the full
message.

It's good to know that setting the full_message can be achieved in this
manner. I still maintain, however, that a :full_message option on the
validation methods would be more intuitive and easier to use. I hope
that someday Rodrigo's patch will be accepted.

Ben

On 1/3/10 4:02 PM, George wrote:
> On Sun, Jan 3, 2010 at 6:30 PM, Ben Munat <bmu...@gmail.com
> <mailto:bmu...@gmail.com>> wrote:
>
>
> If that does exist in Rails 2.x.x somewhere I would really appreciate a
> pointer.
>
>

> It's not on api.rubyonrails.org <http://api.rubyonrails.org> for some

Rodrigo Rosenfeld Rosas

unread,
Jan 3, 2010, 9:48:04 PM1/3/10
to rubyonra...@googlegroups.com
This has been already discussed here, some time ago:

https://rails.lighthouseapp.com/projects/8994/tickets/1687-flexible-formatting-for-ar-validation-error-messages

The key point, in my opinion is that this should not be related to I18n
in my opinion. We should be able to specify the full message without
relying on I18n for that. There are a lot of usages for it and writing
I18n only for getting full control over the messages are overkilling to
me. This is the opposite of agile development, specially if the
application doesn't depend on I18n.

If you have a table field named 'email' but wants "e-mail" to appear
instead, you are forced to use I18n... Same if you have "login" but
wants to use "User name", etc. It would be good to have an api to define
the field humanized names directly in the model too, instead of relying
on I18n for that...

Using I18n when you do not need it is not only overkilling but also
makes the code more unreadable and hard to maintain...

I really would like people to stop associating full message control with
I18n. They are separate things and should not be treated as related each
other. One should be able to control the full message without relying on
I18n for that.

What I really don't see is why there is so much resistance in adding the
:full_message option to validations, since the API was not changed and
the patch doesn't break backward compatibility. There is not to lose
here (at least, I can't see and no one pointed the problems yet).

So, if there is some problem with adding this new very useful option, I
would like to understand what this would be.

Regards,

Rodrigo.

Ben Munat escreveu:

Mateo Murphy

unread,
Jan 4, 2010, 12:05:35 AM1/4/10
to rubyonra...@googlegroups.com

On 3-Jan-10, at 9:48 PM, Rodrigo Rosenfeld Rosas wrote:

I remember that discussion, and I think there was some
misunderstanding. The point being made at the time was that the
feature you were suggesting was not appropriate for rails 2.3.x, since
that was a maintenance branch, but for 3.0 it's a different story. The
resistance you mention is more of a question of timing than
functionality; the I18n approach was suggested as a work around in the
meantime.

In any case, as I mentioned before, we need to figure out what will
happen with the 2.3.4 validation changes first, and as Sven mentioned,
possibly consider some wider API changes before working on
full_message in particular.


Rodrigo Rosenfeld Rosas

unread,
Jan 4, 2010, 4:32:25 AM1/4/10
to rubyonra...@googlegroups.com
Mateo Murphy escreveu:
Yes, I remember that too and that is why I proposed the patch for Rails
edge only. But the resistance that I'm talking about does not come from
that discussion.

It comes from things like this:

"There apparently are lots of edge cases (like various full_messages

features)..."

That is the resistance I am talking about, not the discussion in the past.

As I've said, I can see advantages in restructuring validations
completely and thinking in defining a wider API and that is not a
problem to me.

I would just like the full_message option to not be thought as an "edge
case" and that this option should be in the main API instead of
pluggable in any way...

That is the only resistance I am talking about.

Best regards,

Rodrigo.

Reply all
Reply to author
Forward
0 new messages