Comments (7)
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.
from virtus.
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 theto_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 theto_hash
or theattributes
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
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)
from virtus.
@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.
from virtus.
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.
from virtus.
@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.
from virtus.
@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.
from virtus.
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.
from virtus.
Related Issues (20)
- Publish 1.0.6
- Avoid override of previously assigned attributes
- Put link to dry-rb in README.md to save time for new comers
- possible to dynamically add attributes? HOT 1
- What replaces `ValueObject::InstanceMethods::with`?
- Class not getting initialized HOT 1
- Bug: nil default value of Array attribute ignored HOT 1
- Coerce proc and strict mode don't match
- Default values aren't assigned when initialize method is present. HOT 1
- Array of Array of FooClass
- Strange Boolean behaviour HOT 5
- Validation from class attributes
- Show Embedded value on edit form
- Calling methods inside of a Virtus::Attribute
- Mark as unmaintaned HOT 2
- Hash.try_convert(attributes) errors on params in Rails 5
- FixedWidth Coercion HOT 2
- Date formats HOT 1
- How can I use array of tags(Strings) in a key of a hash? HOT 1
- Strict mode only works for basic values HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from virtus.