Thanks, David B.! Should I add this data tree descriptor idea somewhere? Maybe in a JIRA issue?
Cheers, =David > On Aug 17, 2016, at 6:53 PM, David Bosschaert <[email protected]> > wrote: > > Hi David, > > That fits well with one of the features of the Converter: codecs to convert > to/from serialized types. RFC 215 defines two portable codecs: JSON and > YAML but other implementations can add their own codecs too. > > I haven't implemented the conversion from a 'complex' DTO like the MyTopDTO > described above to those serializations via the codecs, but I think that > might be a good place to start. I'll look into this as it was one of the > things on my todo list already :) > > Thanks, > > David > > On 17 August 2016 at 00:38, David Leangen <[email protected]> wrote: > >> >> Just another thought… >> >> From memory, one of the stated goals of DTOs is that the DTOs are really, >> in a way, nothing more than schema. Because of this, it should be (and is) >> trivial to convert to JSON, XML, YAML, or whatever. >> >> Well, if the DTO _is_ the data structure, then it should also be trivial >> to convert the type descriptor (or tree, or whatever) to some kind of >> schema, like JSON Schema, DTD, XML Schema, RDF… >> >> That would actually be a pretty cool feature, to be able to generate those >> types of schemas. I think it would augment the value of the Converter >> service at relatively little cost. :-) >> >> >> Just my additional 2 Yen. >> >> >> Cheers, >> =David >> >> >> >> >>> On Aug 16, 2016, at 4:50 PM, David Bosschaert < >> [email protected]> wrote: >>> >>> Hi David, >>> >>> Do you mean something like the following: >>> >>> MyTopDTO { >>> int someField; >>> MySubDTO anotherDTO; >>> } >>> >>> MySubDTO { >>> String someString; >>> } >>> >>> Then you'd like to be able to do: >>> MyTopDTO dto = ...; // from somewhere >>> Object stringVal = converter.toTree(dto).valueAt(dto, >>> "anotherDTO/someString"); >>> >>> am I right? >>> >>> Cheers, >>> >>> David >>> >>> >>> On 16 August 2016 at 07:00, David Leangen <[email protected]> wrote: >>> >>>> >>>> Hi! >>>> >>>> The Converter service does a lot of introspection and parsing of the DTO >>>> data structure. In many cases, a DTO is a very simple object structure. >>>> However, it can also be a very complex structure, too. >>>> >>>> According to my understanding of the objectives of the Converter, one >>>> important goal is to be able to persist data. The idea is that the DTO >>>> describes the data, the whole data, and nothing but the data, so help me >>>> Uncle. Thus, it is the ideal way to ship the state of the system off to >>>> PersistenceLand. >>>> >>>> I can buy into this vision. >>>> >>>> If we do buy into this vision, then we may be missing out on a few great >>>> opportunities here. When data gets persisted, we often need to >> understand >>>> the relationships between the embedded objects. Or, we may want to be >> able >>>> to create an index on the data. These are a few of the reasons why we >> would >>>> want to have some kind of x-ray vision on the data structure. Since we >>>> already go through all the trouble of parsing the data structure in >> order >>>> to convert it, and since this is ~95% of the work, it would be really >> nice >>>> to provide access to this information in order to easily link in >> services >>>> that require this intimate knowledge. Otherwise, all the parsing would >> have >>>> to be done over and over again for each service. >>>> >>>> I believe that it would only take a few methods to be able to leverage >> all >>>> the parsing work done by the Converter. I can think of: >>>> >>>> DataTree Converter.toTree(DTO dto); // DataTre gives a tree view of the >>>> structure >>>> Object tree.valueAt(DTO dto, String path); // Dot-separated path value >>>> within the tree structure >>>> void tree.set(DTO dto, String path, Object value); // Set the value at >>>> the given location in the tree structure >>>> void process(DTO dto, Consumer<?> function); // Visit each node for >> some >>>> kind of processing >>>> >>>> Those are just some examples. Perhaps a new API would be necessary, but >> my >>>> main point here is that since we are going through all this work of >>>> implementing a parser, this is the IDEAL time to create this type of >> view >>>> on the data. >>>> >>>> >>>> wdyt? >>>> >>>> I can explain further the idea if you like. For now, I just wanted to >> get >>>> a quick feedback to see if there is any openness to this kind of thing. >>>> >>>> >>>> =David >>>> >>>> >>>> >> >>
