Hi! Is there a (simple) way to use alternative field names in validation messages? For example, if I have a validator like this one: validates_presence_of :email how can I make it print a message like "E-Mail Address can''t be blank" instead of "Email can''t be blank"? I can override the "can''t be blank" part by using the :message parameter, but not the "Email" part. -- \ / vlad@hashbang.de \/lad http://www.hashbang.de
U can override *error_messages_for. *That''s the best way to print specific error messages. Or: validates_presence_of :email, :message => "Address can''t be blank" :) On 6/8/06, Vlad Berditchevskiy <vlad@hashbang.de> wrote:> > Hi! > > Is there a (simple) way to use alternative field names in validation > messages? For example, if I have a validator like this one: > > validates_presence_of :email > > how can I make it print a message like "E-Mail Address can''t be blank" > instead of "Email can''t be blank"? I can override the "can''t be blank" > part by using the :message parameter, but not the "Email" part. > > > -- > \ / vlad@hashbang.de > \/lad http://www.hashbang.de > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Cheers, ioana k&a http://boulangerie.wordpress.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060608/2b43679d/attachment.html
"Ioana Kanda" <kaio4000@gmail.com> writes:> U can override *error_messages_for. *That''s the best way to print specific > error messages.Thank you for pointing that out! I looked at the implementation of this method and now I see that it''s actually ActiveRecotd::Errors::full_messages, which composes a line. Then it calls human_attribute_name, which, for some reason, is not in the documentation. I''m wondering, why there is no standard way to supply *really* human readable names? There are plenty of cases, where simple capitalization of database field won''t do it: - Internationalization - Customization - Legacy schemas - Unusual capitalization or special characters - Sometimes you may just want a better looking name> Or: validates_presence_of :email, :message => "Address can''t be blank" :)Hehe, it won''t print the dash between "E" and "mail". ;-) -- \ / vlad@hashbang.de \/lad http://www.hashbang.de
In the api there is no presence of <human_attribute_name>, aparently, but
I
google it.
def human_attribute_name (attr)
return case attr
when ''email'' then ''E-mail:D''
else super.human_attribute_name attr
end
end
But look what I found:
http://wiki.rubyonrails.org/rails/pages/HowToUseValidationsWithoutExtendingActiveRecord/versions/1
(good article for me to read it too). Heh
--
Cheers,
ioana k&a
http://boulangerie.wordpress.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060608/c5e880ce/attachment.html
"Ioana Kanda" <kaio4000@gmail.com> writes:> def human_attribute_name (attr) > return case attr > when ''email'' then ''E-mail:D'' > else super.human_attribute_name attr > end > endThis seems to be the way to go. There are 2 problems though. First, it must be a class method, otherwise it won''t be found. And second, for some reason super.human_attribute_name can''t be called, I get the following error: ,---- | undefined method `human_attribute_name'' for "Email":String `---- The following code worked for me: ,---- | def self.human_attribute_name (attr) | return case attr | when ''email'' then ''E-mail address'' | # ... | else attr.humanize | end | end `---- I''ll probably make a database table to translate column names to human names and query it in the above method. P.S. I still don''t understand, why super.human_attribute_name(attr) did not work instead of attr.humanize.> But look what I found: > http://wiki.rubyonrails.org/rails/pages/HowToUseValidationsWithoutExtendingActiveRecord/versions/1 > (good article for me to read it too). HehInteresting idea, but not needed in my case, because my model *is* inherited from ActiveRecord::Base. -- \ / vlad@hashbang.de \/lad http://www.hashbang.de
A much delayed comment to this thread... Vlad Berditchevskiy wrote:> P.S. I still don''t understand, why super.human_attribute_name(attr) did > not work instead of attr.humanize.But this works, right? ActiveRecord::Base.human_attribute_name(attr) \David -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---