Closed GoogleCodeExporter closed 9 years ago
Can you please provide a complete example with the YAML document ?
Original comment by py4fun@gmail.com
on 16 Nov 2009 at 11:04
I see this proposal as:
"add a possibility to easily inject a small implementation of either Construct
or
Represent interfaces."
Indeed it should work for simple cases. It may also help to serialize immutable
objects.
Unfortunately anchors and aliases make the picture much more complicated. If
the
Node contains an alias how the simple Construct implementation (without
context!)
can figure out which instance to use ?
Recursive structures make anchors and aliases mandatory.
Original comment by py4fun@gmail.com
on 18 Nov 2009 at 6:26
I don't understand what the problem is yet.
Aliases are resolved during the consturction of the node graph. This is before
the
native objects are constructed.
Original comment by smurn....@gmail.com
on 22 Nov 2009 at 4:23
I am afraid I also do not understand the request.
In the implementation of:
@YAMLConstruct
public static MyDataObj construct(Node node){
...
}
you may need to call something.constructSequence(SequenceNode node). How do you
get the
reference to this 'something' ? Are you talking about scalars only ?
Original comment by py4fun@gmail.com
on 23 Nov 2009 at 3:59
You're right. There's something missing.
What about passing another parameter?
@YAMLConstruct
public static MyDataObj construct(Node node, Constuctor c){
...
c.constructSequence(node)
...
}
Original comment by smurn....@gmail.com
on 27 Nov 2009 at 9:37
I still do not get how this static method can be put into the chain of
constructors.
What about priority ? What happens when users define an explicit constructor
for the
tag and at the same time they have the @YAMLConstruct annotation for the
instance ?
Original comment by aso...@gmail.com
on 27 Nov 2009 at 1:19
I'd give explicit constuctors a higher priority.
Original comment by smurn....@gmail.com
on 27 Nov 2009 at 2:28
I am not so sure this is a good way to do it. Having "everything in one class".
Having in your model's classes something not actually connected to your
domain.... questionable :)
I do not think it is a good idea to put constrain on your model - dependency on
SnakeYAML.
For example you want to use your model on client side. "Everything in one
class" most probably requires snakeyaml classes on your client side, but do you
really need them there?
Why not to adapt JavaBeans way to provide additional info for beans - BeanInfo?
So if you want automatic discovery for the Constructor and Representer - write
some <YourClass>YAMLInfo
(just imaginary name). Make it be at the same package as <YourClass> (or set
YAMLInfo discovery paths, like you can do with Introspector), put it in
classpath. SnameYaml will discover those
classes to get Constructor and Representer from them.
Of course if may decrease performance, but there are always some pros and cons.
:) It could be also in options - to use this technic on not. This is almost
"Everything in one class", but model
and YAMLInfo code can be in different projects (and only one has SnakeYAML as a
dependency).
Original comment by alexande...@gmail.com
on 28 Nov 2009 at 1:37
Good point.
Separation of model and its serialization is a nice thing.
I like the idea of <YourClass>YAMLInfo with automatic discovery. Somehow the
Constructor and Representer should be directly integrated into YAMLInfo.
Otherwise I
have to provide three classes (Constructor , Representer & YAMLInfo) per class.
Original comment by smurn....@gmail.com
on 28 Nov 2009 at 1:59
I do not see an advantage to have the automatic discovery. It can be simply set
to
the Yaml instance at runtime.
Original comment by aso...@gmail.com
on 28 Nov 2009 at 2:33
Yep. in most cases this is not necessary.
But may give a possibility not to change already working/tested code if your
domain/model grows.
You do not need to change any code where Yaml instance is used, just drop new
classes and their "YAMLInfos" to
classpath and ... they will be correctly dumped and loaded using the same code
(of course if Representer and
Contructor are correct) :)
Original comment by alexande...@gmail.com
on 28 Nov 2009 at 6:50
Since the reporter is not interested in the topic any more I will close the
issue.
Original comment by aso...@gmail.com
on 20 Dec 2009 at 10:49
Original issue reported on code.google.com by
smurn....@gmail.com
on 13 Nov 2009 at 5:21