Introduce Yaml.loadAs() and Yaml.dumpAs() methods

[GoogleCodeExporter]

Try to implement the recommendation: 
https://groups.google.com/d/topic/snakeyaml-core/wkzG-4BCNmw/discussion

Try to process JavaBeans and type-safe collections.

Original issue reported on code.google.com by py4fun@gmail.com on 4 Jul 2011 at 11:33

[GoogleCodeExporter]

loadAs() methods can be implemented with a minor backwards incompatible change.
See http://code.google.com/r/py4fun-loadasbeans/source/list

Original comment by py4fun@gmail.com on 4 Jul 2011 at 6:31

• Changed state: Started
• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

The change looks good so far: good work. I only have one concern with the 
change so far, which is that JavaBeanLoader lets you use TypeDescription for 
the root type, but there are no loadAs() methods to replace that function. If 
that change is intentional I don't see a problem with it.

Original comment by JordanAn...@gmail.com on 4 Jul 2011 at 8:11

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Thank you Jordan for the idea!
I did not quite catch your concern. In fact JavaBeanLoader did not use the 
whole TypeDescription for the root type. It was just setting the tag for the 
root Node.
(I am afraid I might misunderstand your question.)

Original comment by aso...@gmail.com on 4 Jul 2011 at 9:20

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

You understood me perfectly, I just hadn't looked closely enough at what 
JavaBeanLoader did. It looks like we don't need methods to deal with 
TypeDescription, which is good (keeps the API complexity down).

While we're removing deprecated classes, we may as well remove JavaBeanParser, 
as it has been deprecated for almost two years now.

Original comment by JordanAn...@gmail.com on 4 Jul 2011 at 9:31

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

I agree: JavaBeanParser has been removed.

Original comment by py4fun@gmail.com on 5 Jul 2011 at 7:11

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

It is unclear what to do with JavaBeanDumper. I would like to deprecate it. All 
its business is just to set two settings in DumperOptions:

setExplicitRoot(Tag.MAP);
setDefaultFlowStyle(flowStyle);

Original comment by py4fun@gmail.com on 5 Jul 2011 at 9:17

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

I would suggest deprecated in 1.9, removed in 2.0.

Original comment by JordanAn...@gmail.com on 5 Jul 2011 at 8:07

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

What I mean is: I do not know how to apply settings used in JavaBeanDumper. In 
order to deprecate it we need to provide a better way to serialize a JavaBean. 
What it should be ? How to dump a JavaBean ? I would like to have a simple way 
and avoid the root tag with the class name because it is redundant.

Original comment by py4fun@gmail.com on 6 Jul 2011 at 6:56

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

what about something similar to loadAs(...)  ?

Original comment by alexande...@gmail.com on 6 Jul 2011 at 9:39

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

About dumpAs()
1) Yaml instance has its own DumperOptions. If in this DumperOptions there is a 
custom setting for the root tag or for the flow style which setting should be 
more important ?
2) dumpAs is not a good name because there will be no additional argument with 
a class.
So it can be named 'dumpClass'. Since it will have the same argument(s) as 
existing 'dump' methods, it may be confusing for users which one to pick up.

I think there shall be a very easy way to provide a proper DumperOptions 
instance. But how ?

Original comment by py4fun@gmail.com on 6 Jul 2011 at 11:17

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

My opinion is that dumpAs() should take a Tag as the second argument. For 
example, JavaBeanDumper's current behaviour would be similar to: yaml.dumpAs ( 
object, Tag.MAP );

I don't think the configuration (DumperOptions settings) applied in 
JavaBeanDumper is particularly special. A little bit of documentation showing 
users how to change these settings for a Yaml object is better than bothering 
to duplicate this behaviour directly. Users can provide a DumperOptions 
instance to Yaml as a constructor argument.

The big thing that can only be easily done through JavaBeanDumper is to dump 
something without a root level tag, or with a different root level tag. This is 
what we must duplicate in dumpAs().

Original comment by JordanAn...@gmail.com on 6 Jul 2011 at 12:39

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

yaml.dumpAs(object, Tag.MAP) is also confusing: it looks like users are free to 
define the second argument. But in fact, we want to enforce 'Tag.MAP'. What 
happens if they say yaml.dumpAs(object, Tag.SEQ) ? What do we do with the flow 
setting?

We can stick to 'yaml.dumpClass(object)' but what happens if users try to dump 
a list with such a method ?

Original comment by py4fun@gmail.com on 6 Jul 2011 at 3:38

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Do we necessarily want to enforce Tag.MAP? What if I want to dump some object 
with a custom Represent instance as a Tag.SEQ? Or as Tag.PAIRS?

If you say yaml.dumpAs(object, Tag.SEQ), then object is dumped with the 
sequence tag, like you asked it to do. It may not be possible for you to load 
it back easily, but it did exactly what you told it to do. 

I can imagine a circumstance where I have an object (MyObject), with a custom 
Represent instance, that I would like to dump tagged as a Sequence: 
yaml.dumpAs(myObject, Tag.SEQ) . The custom Represent instance returns a 
SequenceNode. Then I can use yaml.loadAs(document, MyObject.class) to load the 
object with the correct type, but the document can still be loaded as a 
Sequence (list, array, whatever) if that type is not available.

Ultimately, more thought needs to go into how nodes are tagged in output, both 
for cross-language communication and for customization. However, this is a 
good, simple start.

Original comment by JordanAn...@gmail.com on 6 Jul 2011 at 4:01

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Should we introduce a factory which creates Yaml instances configured for 
different needs ? Then it is easy to get an instance where DumperOptions object 
is pre-configured to serialize JavaBeans ? (with no root tag and with better 
flow)

Original comment by py4fun@gmail.com on 7 Jul 2011 at 8:11

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

I don't think so. If anything, a DumperOptions factory would make more sense, 
but this is such a small bit of configuration that there's no point creating 
more code to maintain it. Writing a comment or some documentation on how to 
return to the old behaviour (supply a DumperOptions with FlowStyle set...) 
would be better.

Original comment by JordanAn...@gmail.com on 7 Jul 2011 at 2:50

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

I think we may also make setDefaultFlowStyle(FlowStyle.BLOCK) the default 
setting. Then only one setting is left - for the root tag.

Original comment by py4fun@gmail.com on 11 Jul 2011 at 10:59

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

I support changing the default flow style to FlowStyle.BLOCK .

Original comment by JordanAn...@gmail.com on 11 Jul 2011 at 8:42

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

I agree with FlowStyle.BLOCK by default.

Original comment by alexande...@gmail.com on 13 Jul 2011 at 9:20

• Added labels: ****
• Removed labels: ****