Deprecated error_messages, what to use now?

cojones · September 17, 2010, 12:54pm

Hey,

as you all may know error_messages are deprecated:
DEPRECATION WARNING: f.error_messages was removed from Rails and is now
available as a plugin. Please install it with rails plugin install git://github.com/rails/dynamic_form.git

Installing the plugin of course helps but I’ve been googling a bit and
stuff but couldn’t find the proper new Rails 3 way of handling the error
messages. Can someone please tell me how to do it without that plugin?

cojones · September 17, 2010, 1:06pm

On 17 September 2010 11:54, Heinz S. [email protected] wrote:

as you all may know error_messages are deprecated:
DEPRECATION WARNING: f.error_messages was removed from Rails and is now
available as a plugin. Please install it with rails plugin install git://github.com/rails/dynamic_form.git

Installing the plugin of course helps but I’ve been googling a bit and
stuff but couldn’t find the proper new Rails 3 way of handling the error
messages. Can someone please tell me how to do it without that plugin?

I believe the idea is that you can write your own helper method to
format the errors exactly how you want them. You can access the error
messages directly by using the #errors method on the Active Record
object; for example:

person.errors.full_messages

Documentation for that is here:

The source for the error_messages_for method in the dynamic_form
plugin might also be a source of ideas:

github.com

rails/dynamic_form/blob/master/lib/action_view/helpers/dynamic_form.rb#L183


      
          # You can also use a number of objects, which will have the same naming semantics
          # as a single object.
          #
          #   error_messages_for @user, @post
          #
          # If the objects cannot be located as instance variables, you can add an extra <tt>:object</tt> parameter which gives the actual
          # object (or array of objects to use):
          #
          #   error_messages_for 'user', :object => @question.user
          #
          # NOTE: This is a pre-packaged presentation of the errors with embedded strings and a certain HTML structure. If what
          # you need is significantly different from the default presentation, it makes plenty of sense to access the <tt>object.errors</tt>
          # instance yourself and set it up. View the source of this method to see how easy it is.
          def error_messages_for(*params)
            options = params.extract_options!.symbolize_keys
          
          
  objects = Array.wrap(options.delete(:object) || params).map do |object|
              object = instance_variable_get("@#{object}") unless object.respond_to?(:to_model)
              object = convert_to_model(object)
          
          
    if object.class.respond_to?(:model_name)

Chris

cojones · September 17, 2010, 1:53pm

Alright, thanks! Will build my own helper method then.

cojones · November 12, 2010, 4:27am

Ok, guys, we can write our own helper… but why, when it is ready?

Start (with Rails 3) a new project and scaffold a dummy resource.
Then, copy the error handling from the _form partial thus generated and
adapt it to your needs.

It think it is the best way to learn how to code as an insider, provided
scaffolding is maintained by insiders.

HTH better

cojones · November 12, 2010, 12:34pm

I meant “if it is already done”… and I meant “previously, by someone
else”, but, ok, two months is time enough for some hundreds of helpers

cojones · November 12, 2010, 8:12am

What do you mean by “when it is ready?” It is kinda ready