Rails Ruby on Rails

Comments and changes to this ticket

• You flagged this item as spam.
  

  Claudio Poli October 1st, 2010 @ 11:21 AM

  • Importance changed from “” to “”

  I would love to see this aswell.

  I can try aswell to build a patch for this, ideas?

• 

  José Valim October 8th, 2010 @ 10:10 PM

  • State changed from “new” to “stale”
• 

  José Valim October 8th, 2010 @ 10:11 PM

  • State changed from “stale” to “new”

  Ops, marked as stale by mistake. What are the functionality you are trying to achieve here guys?

• You flagged this item as spam.
  

  Luke Melia October 8th, 2010 @ 10:18 PM

  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.

• 

  José Valim October 8th, 2010 @ 10:25 PM

  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.

• You flagged this item as spam.
  

  Luke Melia October 8th, 2010 @ 10:28 PM

  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.

• You flagged this item as spam.
  

  codemanki October 8th, 2010 @ 10:36 PM

  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
  


  {mkd-extraction-af5c172a54ff976221305bb9b6567afa}

  
  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?

• You flagged this item as spam.
  

  codemanki October 8th, 2010 @ 10:38 PM

  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
  

• 

  José Valim October 9th, 2010 @ 07:02 PM

  "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?

• You flagged this item as spam.
  

  codemanki October 9th, 2010 @ 08:04 PM

  @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.

• 

  José Valim October 9th, 2010 @ 08:16 PM

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

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

  Or am I missing something?

• You flagged this item as spam.
  

  codemanki October 9th, 2010 @ 08:23 PM

  @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?

• 

  José Valim October 9th, 2010 @ 08:26 PM

  • State changed from “new” to “wontfix”

  So far yes. :) However I can gladly reopen it if a valid use case is given.

• You flagged this item as spam.
  

  Claudio Poli October 15th, 2010 @ 04:35 AM

  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 :)