Rodrigo Rosenfeld Rosas
2011-Mar-21 14:00 UTC
ActiveModel Serialization API: design and documentation
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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Evgeniy Dolzhenko
2011-Mar-21 14:12 UTC
Re: ActiveModel Serialization API: design and documentation
> It doesn''t make much sense to me how the Serialization API is designed > and documented currently. Let me split both subjects.> ... Confirmed, had the same issues trying to use AM serialization on my custom (non-AR) models. There is also another thing which I find confusing. ActiveModel::Serializers::JSON relies on serializable_hash method provided by ActiveModel::Serialization. ActiveModel::Serializers::Xml for some reason doesn''t use that instead reimplementing serializable_hash from the scratch. In other words overriding serializable_hash would only affect JSON serialization and not Xml one -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Nick Sutterer
2011-Mar-22 17:01 UTC
Re: ActiveModel Serialization API: design and documentation
Same thing here - I tried to reuse the Serialization API but found it way too complex and confusing, I think a rewrite would be best - still not sure why AM doesn''t use ActiveSupport''s serialization, though. That would make things much clearer. Nick On 21 Mrz., 15:12, Evgeniy Dolzhenko <dolze...@gmail.com> wrote:> > It doesn''t make much sense to me how the Serialization API is designed > > and documented currently. Let me split both subjects. > > > ... > > Confirmed, had the same issues trying to use AM serialization on my > custom (non-AR) models. There is also another thing which I find confusing. > > ActiveModel::Serializers::JSON relies on serializable_hash method > provided by ActiveModel::Serialization. > > ActiveModel::Serializers::Xml for some reason doesn''t use that instead > reimplementing serializable_hash from the scratch. > > In other words overriding serializable_hash would only affect JSON > serialization and not Xml one-- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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 <rr.ro...@gmail.com>
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 rubyonrails-core@googlegroups.com.
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
Would it be possible to have a generic Serialization class that uses delegates to perform Serialization to different formats? It seems the reason why there is a different interface for xml as their is to json is that rails implements an number of "to_json" methods to a whole lot of existing classes (including Object). Using a delegate for active model would unify the interface at last for active model and allow base level to_json implementations to work in their own regard. I have some time to spend on this and would love to submit a patch or two :) but as I am new around here I would love some feedback as to if this could get in or what I would have to do to get to work on cleaning up the code a little. On Mar 28, 12:50 pm, Stewart <stewart.mathe...@gmail.com> wrote:> 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 <rr.ro...@gmail.com> > 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.