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
