I have been thinking about this as well. First time I have added to a
discussion about core so throw the book at me but,
It seems somewhat limiting to make Serialisation generic for all
formats as there might be a use case where different attributes may
need to be serialised for different formats. I guess the next step
from that would be writing different methods in the model. So a method
called "attributes_as_json" could be written. Thinking about this
does not seem right for a model though. It would add methods to models
that are getting away form business rules. Thats why having
attributes in the model does not seem to make sense to me.
One solution from a user POV would be to make setting options
when .as_json or as_xml is called. This would add controller code
however I would allow for a more generic method of serialisation
accross different formats. It would also allow for more flexable web
service design as your not locked in to the same attributes in your
controllers. Why not have as_json and to_xml pass a block to
serializable_hash which builds the hash of options and then delegates
to what ever encoder needs to be used. That way you would avoid code
that looks like this...
format.js { render :json => @shifts.to_json( { :include =>
{ :users =>
{ :only =>
[ :id, :first_name, :last_name ] }
},
:exclude =>
[ :active, :created_at, :updated_at, :occurrence, :company_id ]
}
)
}
YAY my first post to core!!!
On Mar 22, 1:00 am, Rodrigo Rosenfeld Rosas <[email protected]>
wrote:
> It doesn't make much sense to me how the Serialization API is designed
> and documented currently. Let me split both subjects.
>
> Design
>
> Why does the API require an 'attributes' method if the module only uses
> its keys? I guess attributes should either return an array of the keys
> to be serialized or be renamed to something like 'attribute_keys'.
> Another option would be ActiveModel::Serialization to maintain the
> attributes hash up-to-date as well as using the initial values of the hash.
>
> It seems the API is designed this way so that it fits the ActiveRecord
> API. But for this to make sense as an independent module, it should
> implement more from ActiveRecord like maintaining the attributes hash
> up-to-date.
>
> Documentation
>
> What is the reason for 'to_json' not appearing in generated
> documentation? I mean, "to_json" is documented in the "as_json" method
> but the last one returns a hash while the former returns a string.
>
> Thanks in advance,
>
> Rodrigo.
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Core" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
