Add options[:procs] to to_json

I think the common use case is building an API for your web app that supports output in either xml or json. Ideally, you could use the same types of options both to_json and to_xml. As it is today, to_json is underpowered compared to to_xml.

Luke, it sounds good, but each option needs to be analyzed by itself. For example, at first it seems it does not make sense to support options[:procs] for JSON since, in the XML case, it yields the builder object which does not exist for JSON. But I believe other options may be welcome.

Agreed, Jose. When I ran into this problem, I initially set out to unify the interfaces, but quickly saw that the internals are so different that it was not an easy course to chart. Instead, I wrote adapter classes for my models that handled the xml/json rendering cleanly. Looking back, my code is cleaner than it would have been if to_xml and to_json worked as I wished they did.

Here is my opinion. I did a little research on serialization :).
When you do
User.first.to_xml(:procs => [Proc.new{|options|}])
OR
User.first.to_xml(:procs => [Proc.new{|options, serializable|}])
You can access Builder which options[:builder] constructs xml through and serializable model.
rails/activemodel/lib/active_model/serializers/xml.rb line 100



So, it means that you can influence the xml tree.

In json situations, you have a hash. So maybe we can just pass hash to proc?

Oh. something hapened with code.
rails/activemodel/lib/active_model/serializers/xml.rb line 100

      @builder.tag!(*args) do
        add_attributes_and_methods
        add_extra_behavior
        add_procs
        yield @builder if block_given?
      end

"In json situations, you have a hash. So maybe we can just pass hash to proc?"

Can you give real life examples of this? Why would you need it for? What is the output you expect once you pass a proc?

@José Lets say, i have
User.first.to_json , and it will return something like "{"login": "codemanki", "email": "mail@gmail.com"}"
And i can do
proc = Proc.new{|serializable| serializable.merge({:can_login => true})}
User.first.to_json(:procs => [proc])
and so it will return "{"login": "codemanki", "email": "mail@gmail.com", "can_login": "true"}"

Yes, i know that we can achieve this by adding method to User model and then passing it to to_json like .to_json(:methods => :mymethod), but maybe :procs will be much easier and clear way to edit result json right in the spot, without adding methods to model?

This is a simple example that comes to mind.

I am still skeptical. This could be easily done as:

render :json => @user.as_json.merge(:can_login => true)

Or am I missing something?

@José No, you are not missing. It can be done in this way too. Or even @user.as_json.merge(:can_login => true).to_json :)
So, you think this is unnecessary feature?

The case here is to try and share the same options to both to_xml and as_json/to_json overrides.

For example, if we include in :methods an instance method that returns a Hash, to_xml does not behave correctly and prints out a string; I need to add it to :procs and customize it a little, while as_json/to_json works as expected.

So if to_json accepts a proc aswell I can keep the same code and take out the :methods parameter.

This is a solution and there are a dozen for this problem anyway, but you asked for a use case :)