Propagation of include and exclude

[trailblazer]

Propagation of include and exclude

[apotonick]

Matt- the :include and :exclude options are filtered out on the first level per design. They should be used very moderately since we don't wanna end up with the same problems (aka shit) :as_json's hash madness had. However, if there's a bunch of people requiring this we could discuss it.

[mpeychich]

Perhaps a way to specify them on the property would be an effective way of doing it. In Roar you can use :embedded => true to put the property in _embedded, perhaps allowing :include, :exclude or a way to pass an options hash for serialize/deserialize in a similar fashion.

As a simplified use case, consider the above example and adding a property on AlbumRepresenter for an Artist which is extended by ArtistRepresenter and two different UIs that might consume the data, cover-flow and detailed list. Cover-flow may want an Artist and their Albums but only album artwork and title.

module ArtistRepresenter
  collection :albums, :extend => AlbumRepresenter, :serialize_options => lambda {|opts| opts.delete(:albums)}
end

:serialize_options takes a NilClass, Hash or Proc and is ignored if nil or absent. This would allow a client to consume the data it wants for its needs while allowing the developer to maintain a single representer. It does not duplicate the same crap as :as_json with :include and :except hash madness, but allows the developer the ability to specify serialization options in the code explicitly or as generated by their own means via options passed to to_hash or to_json

# For cover-flow where songs are not needed
artist.to_hash(:albums => {:include => [:title, :album_artwork]})

# For detailed list where album artwork is not needed
artist.to_hash(:albums => {:except => [:album_artwork]})

[mpeychich]

Nick - After reading through the TODO file, what I think I am after is essentially the representer_options with the ability to use a Proc or Hash