felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Bosschaert <david.bosscha...@gmail.com>
Subject Re: [Converter] Data Tree Structures
Date Wed, 17 Aug 2016 09:53:39 GMT
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 <osgi@leangen.net> 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 <
> david.bosschaert@gmail.com> 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 <osgi@leangen.net> 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
> >>
> >>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message