Zeus: Re: Binding: Master Plan

[Spencer A Marks <smarks@xxxxxxxxxxxxxxxxx>]

Hi,

I like the decoupling of the binding from the generator. I see the
big advantage in not having to tweak the generator once a solid
binding interface has been defined. Also, having the flexibility of
multiple input formats is useful too. I definitely wouldn't worry
about any performance issues that might be incurred as part of this
abstraction.

I have a couple more comments/questions below


"Brett McLaughlin" <brett@xxxxxxxxxxxxxxx> writes:
> 
> As for Bindings, I see two core classes:
> 
> Objects, and Properties. However, I don't want to call anything an object.
> And there is clearly confusion over why a property would not be an object.
> So instead, I prefer:
> 
> Containers and Properties. These would both derive from Binding, and the
> former is of course capable of "containing" things, while the latter is a
> member of something. In addition, you have further breakdown: an
> AtomicProperty would be a simple name/value/type deal. However, a
> ContainerProperty would be a property of another Container, yet also could
> contain things itself (this is essentially an Object, like a List). So I see
> this hierarchy in our Bindings:
> 
>                 Binding
>                 /     \
>                /       \
>        Container      Property
>             \          /     \
>              \        /       \
>        ContainerProperty     AtomicProperty
> 
> I can't quite come up with a Container derivation that isn't a Property,
> though. Of course, the base Container could be a top level object. So you
> might have:
> 
>   Container
>     |
>     |- AtomicProperty
>     |
>     |- AtomicProperty
>     |
>     |- ContainerProperty
>          |
>          |- AtomicProperty
>          |
>          |- ContainerProperty
> 
> (And so on)
> 
> Make sense? That, as simple as it is, really represents the types you end up
> with in Java.

I am probably being dense here, but isn't this just another tree
structure? We'd be mapping the XML DOM (tree) to this one? What am I missing?



> This will take in a binding, and then output the resultant classes to a
> Result. The reason that it doesn't take a Binder is that it is possible that
> we may want to provide transformations of Bindings. This is the JSR-31
> full-blown version where there is a "binding schema" that specifies mappings
> from the constraints to class generation. For example, a Foo in the
> constraints may actually become a Bar in Java. We aren't going to add this
> into the first version, but this framework easily allows for it, as I see
> it. So we'll provide an initial SimpleGenerator, that probably provides (as
> convenience):
  
I am little confused here, but I should read JSR-31 more thoroughly before
asking for clarification. 

> 
> public void generate(Binder binder, Result result) {
>   generate(binder.getBinding(), result);
> }
> 
> More complex Generator impls can come later.
> 
> [Side Note: Result abstracts an output. We will provide a concrete
> StreamResult, and we will also have Source for input, and provide
> StreamSource. If these ring a bell, they are from the TRAX concept, which I
> think is a good idea]

I haven't heard of TRAX, can you supply a pointer?

Thanks. 

Spencer
-----------------------------------------------------------------------------
To unsubscribe from this mailing list, send email to majordomo@xxxxxxxxxxx
with the text "unsubscribe zeus" in the body of the email.
If you have other questions regarding this mailing list, send email to
the list admin at owner-zeus@xxxxxxxxxxxx