offer json + xml de/serialization

[mkristian]

offer json + xml de/serialization

[senny]

how would you like to serialize the virtus-objects? I don't like the to_xml and the to_json methods very much. I guess it should not be the responsibility of a domain model to convert itself to xml or json.
I'd rather like an other class with relies on the to_hash or the attributes method to know what to serialize.

[mkristian]

On Wed, Nov 16, 2011 at 12:46 PM, Yves Senn
[email protected]
wrote:

how would you like to serialize the virtus-objects? I don't like the to_xml and the to_json methods very much. I guess it should not be the responsibility of a domain model to convert itself to xml or json.
I'd rather like an other class with relies on the to_hash or the attributes method to know what to serialize.

something like

Serializer.to_json(model, options)

is not very useful since in the past I needed to overwrite the
model.to_json method in some cases which I can not do with such a
"Serializer".

maybe something like

MyModelSerializer < Serializer

with

my_model_serializer.to_json(model, options)

will do. my personal usecase is to get these models over the wire
using something like

https://github.com/c42/wrest

after the de/serialization is clear then I will need some
Wrest::Translators from/to virtus models.

• Kristian

---

Reply to this email directly or view it on GitHub:
#38 (comment)

[dkubb]

@senny I would like to second your aversion to #to_* methods. I really dislike the idea of adding methods to domain objects for convenience. At the very least, design the system so it is decoupled and allow people to optionally add a #to_* method that basically just delegates to the serializer.

When I think of objects that handle JSON or XML serialization, I usually create a presenter object that knows how to handle serialization. By default it could call #to_hash on the object and just serialize that. A more comprehensive system could allow you to specify which fields to show/hide.

Ideally what I would want is something that knows next to nothing about Virtus objects. It should be possible to handle it a Virtus, DataMapper or even ActiveModel object and have it handle serializing. Of course you can have "glue" that knows how to reflect on specific types of objects to help things along, but I think the base serializer should have no coupling at all.

[dkubb]

I should also mention one other thing, and this probably is better off in a manifesto or somewhere it's going to be read more often, but the thing we're going for with Virtus, Veritas, DataMapper 2 and related projects is that were't trying not to build an ecosystem of libraries that only work together. We want things that stand on their own.

It would be a shame if we had gems like virtus-serializer or datamapper2-validations, except as thin glue code to make virtus work with a not-yet-created serializer lib, or datamapper to work with a kick-ass validator library. I really think we need to focus on making things that are awesome on their own.

At the same time, we're trying to make sure the API design, documentation, specs and other things are cohesive between these loosely coupled components. It would be a shame if things were so disjointed between the libraries that the style one library uses is completely different from the other. Obviously this is something we need to always be vigilant about, but I think most of us involved with the various subprojects roughly agree on stylistic choices and/or are open to finding better and more consistent ways to do things.

[dkubb]

@mkristian what about something like:

# initialize a domain object
person = Person.new(:name => 'John Doe')

# a simple decorator wrapping the domain object
serializer = PersonSerializer.new(person)

# serialization methods
serializer.to_xml
serializer.to_json

Where PersonSerializer is something like:

class PersonSerializer < Serializer
  # customize mapping for Person, hiding sensitive data or adding associated objects
end

And Serializer as:

class Serializer
  def initialize(subject)
    @subject = subject
  end

  def to_json(options = {})
    # serialize the subject to JSON
  end

  def to_xml(options = {})
    # serialize the subject to XML
  end
end

One other thing I might suggest to anyone considering serialization is to consider deserialization at the same time. I'm not really talking about all in the same class, more just thinking about how you're going to parse the data afterwards. It would be really interesting to build both sides at the same time, having each around to verify the other is working as expected. You can even test things like "round tripping", where you serialize an object, deserialize it, and then compare it against the original. IMHO the goal should be to strive towards being able to round-trip every type of object without any data loss.

[mkristian]

@dkubb
your suggestion is quite close to what I wrote.

my motivation is get away from ActiveModel (for some reasons), deserialization needs some kind of factory method.

Deserialize.from_json(model_class, hash)

where the model_class needs an initializer like

class Person
  def initializer(hash)
   ...

for the serializer a to_hash or attributes is sufficient requirement. yes, round trip testing is what I usually do for my serailziers for GWT.

[solnic]

Virtus will never include any serialization features. The reason why there's #to_hash is that it's needed for EmbeddedValue which will be added soon.

Regarding Serialization - not so long ago I suggested creating a standalone library designed to handle serialization which does not depend on anything. It would know how to serialize objects if they respond to certain methods (ie #attributes). I also don't like #to_* methods being mixed into your domain objects and this is exactly why I suggested a standalone library. It would be another 'piece of the puzzle' that would become a part of DataMapper 2.0 but it would also work standalone - just like Veritas, Virtus and Aequitas.

We believe that creating libraries that are focused on solving only one problem is much better than monstrosity-libs that do everything. This way everybody wins because you can cherry-pick a certain set of libraries to build a new system or just use 'a bundle' of libraries called DM 2.0. Another benefit is that working on a small library is so much easier than dealing with too many concerns at the same time which is the case when, for example, you're creating an ORM with all the extra features built-in. Even if the end result means a little more code (because I can imagine some 'glue' code will be required in some cases to make the libs work together) it's still worth to do it.