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 >> >> >>
