Hi guys,
It's a really nice idea to make it easier to write custom converters. Just
a suggestion, on the API side, another approach would be to make the node
methods static factories so one could expand the DSL without having to
modify xstream's code:
static ConverterPartConfig node(String name) {
return new ConverterPartConfig() {
public void apply(Object source, HierarchicalStreamWriter writer,
MarshallingContext context) {
writer.startNode(); writer.convertAnother(reflectGet(source, name));
writer.endNode();
}
};
}
When someone else wants to add new methods to the DSL, instead of modifying
XStream ,he can write new Config factories.
Regards
guilherme
Guilherme Silveira
Caelum | Ensino e Inovação
http://www.caelum.com.br/
On Fri, Oct 12, 2012 at 9:47 PM, Ander Parra <[email protected]> wrote:
> Hi Jörg, I changed the project name. Please, use this URL
> https://github.com/aparra/xstream-dsl for view project.
>
> I expanded the idea and now, you can use the dsl to write marshal and
> unmarshal objects.
> I'm using in my job for build rest services.
>
> I'm waiting for your feedback.
>
> Regards,
> Ander Parra
>
> On Friday, October 12, 2012, Jörg Schaible wrote:
>
>> Hi Anderson,
>>
>> sorry for this late response, but somehow I got side-tracked when my first
>> look for your code simply gave me a 404 at Github. I finally found it
>> though.
>>
>> Ander Parra wrote:
>>
>> > Hi Joe! Cool you liked! Thanks.
>> >
>> > The # prefix is to differentiate beans attributes and node names.
>> > Everyone I showed, asked about # prefix. I'll remove it in the next
>> > commit.
>> >
>> > This weekend I will begin creating documentation. I received positive
>> > feedback about the dsl, I'm starting to use it in developing, we'll
>> > probably have more evolutions.
>> >
>> > I want to contribute more to the xstream project, it's cool!
>> >
>> > I warn you about updates.
>>
>> Actually it is a cool idea to use a DSL for a writer (and reader), but
>> normally I would expect that the DSL would actually help me to avoid
>> errors
>> i.e. in case of the writer it should understand the writer's state.
>>
>> E.g. when a converter is called, the internal state of the writer is
>> essential for the converter's implementation. Directly after entering the
>> method it is the only time where you can actually write attributes or you
>> may continue directly with a value or a child. And after writing a simple
>> value, you may not add anything else nor should it be possible to write a
>> value after adding a child.
>>
>> Your current implementation allows me to call your methods in arbitrary
>> order (you do not even force me to call the "to" method first) and your
>> separation between attributes and child elements is simply based on name
>> conventions (using the '#' character). You can do better :)
>>
>> Another itch is that your functionality actually starts to reimplement the
>> ReflectionConverter. Initially you had only support for the primitive
>> value,
>> but you started to support stuff like dates with formatting capabilities
>> or
>> collections. XStream's normal model is based on its pluggable converters,
>> but here you've create a completely alternative implementation bypassing
>> the
>> existing functionality. Therefore I fear actually the maintenance in the
>> long run.
>>
>> [snip]
>>
>> - Jörg
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>>
>
> --
> Anderson Parra
> cel.: (11) 9761-3862
>
