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 >>> <mailto:rubyonrails-core+unsubscr...@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 >> <mailto:rubyonrails-core+unsubscr...@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. > 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. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
