full_message option added to Rails validations

rubyonrails-core
1

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.

2

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

3

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! :slight_smile:

Thanks,

Rodrigo.

Mateo Murphy escreveu:

4

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.

5

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:

6

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

7

It’s possible since (iirc) 2.3.3.

I have no idea why people keep repeating it’s not possible. Maybe a documentation issue.

8

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

9

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.

10

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

Probably a recent documentation, the API docs are not updated often.

12

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

13

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:

14

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.

15

Mateo Murphy escreveu:

This has been already discussed here, some time ago:

#1687 Flexible formatting for AR validation error messages - Ruby on Rails - rails      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.

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.