Providing Construct/Representer logic within the Class

[GoogleCodeExporter]

If the defaults are not enough, I have to write a Construct and a
Representer class. Sometimes it would be nice to have everything in one
class. Especially if only a few lines of code are requried.

This could look like this:

public class MyDataObj{

    ...
    ...

    @YAMLConstruct
    public static MyDataObj construct(Node node){
        ...
    }

    @YAMLRepresent
    public Node represent(){
        ...
    }
}

It would be even better if snakeyaml would automatically recognize the
annotations, such that no explicit registration is required. 

Original issue reported on code.google.com by smurn....@gmail.com on 13 Nov 2009 at 5:21

[GoogleCodeExporter]

Can you please provide a complete example with the YAML document ?

Original comment by py4fun@gmail.com on 16 Nov 2009 at 11:04

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

I'd give explicit constuctors a higher priority.

Original comment by smurn....@gmail.com on 27 Nov 2009 at 2:28

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

[GoogleCodeExporter]

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

• Changed state: WontFix