Rails - Jun 2006 - Field names in validators

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
> end
This 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). Heh
Interesting 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
-~----------~----~----~----~------~----~------~--~---