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> > 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 > > > On 1/3/10 2:36 PM, Sven Fuchs wrote: > > It's possible since (iirc) 2.3.3. > > > > I have no idea why people keep repeating it's not possible. Maybe a > > documentation issue. > > > > > > On Jan 3, 2010, at 11:15 PM, Ben Munat wrote: > >> 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 > >> > >> > >> On 1/3/10 5:17 AM, Rodrigo Rosenfeld Rosas wrote: > >>> 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. > >>>> > >>>> 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. > >>>> > >>>> On Jan 3, 2010, at 4:05 AM, Mateo Murphy wrote: > >>>> > >>>> > >>>>> 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 > >>>>> > >>>>> On 2-Jan-10, at 5:52 PM, Rodrigo Rosenfeld Rosas wrote: > >>>>> > >>>>> > >>>>>> 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. > >>>>>> > >>> > >>> -- > >>> > >>> 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-core@googlegroups.com > >>> <mailto:rubyonrails-core@googlegroups.com>. > >>> To unsubscribe from this group, send email to > >>> rubyonrails-core+unsubscr...@googlegroups.com<rubyonrails-core%2bunsubscr...@googlegroups.com> > >>> <mailto:rubyonrails-core+unsubscr...@googlegroups.com<rubyonrails-core%2bunsubscr...@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 rubyonrails-core@googlegroups.com > >> <mailto:rubyonrails-core@googlegroups.com>. > >> To unsubscribe from this group, send email to > >> rubyonrails-core+unsubscr...@googlegroups.com<rubyonrails-core%2bunsubscr...@googlegroups.com> > >> <mailto:rubyonrails-core+unsubscr...@googlegroups.com<rubyonrails-core%2bunsubscr...@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 rubyonrails-c...@googlegroups.com. > > To unsubscribe from this group, send email to > > rubyonrails-core+unsubscr...@googlegroups.com<rubyonrails-core%2bunsubscr...@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 rubyonrails-c...@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscr...@googlegroups.com<rubyonrails-core%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. > > > -- 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-c...@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
