On Nov 8, 2015 16:32, "Kent Sølvsten" <[email protected]> wrote:
>
> Hi Niclas
>
> Interesting!
>
> I have always found the syntax regarding private mixins (especially the
> quite large inner classes) a bit weird. So any improvements here would
> be great.
Well, you don't need to make the private Mixins as inner interfaces. Works
equally well with top level interfaces, it is just I who think it is
convenient to have everything in the same place.
> An interesting thought: Could it be possible to create a
> JpaEntityAssociationStateDecorator? (not sure it is really a good idea,
> might be too complicated
> and integration might be better done by integrating the UOW with the
> global transaction management).
A little bit hard to see the complications. Are you talking about a Zest
entity composites behaving like JPA persistence capable beans?? Or the
other way around?
> Not quite convinced that core is the right place though - it probably
> depends on how certain we are to get the API right the first time. So a
> library *might* be better.
Yeah perhaps that is a good reason.
> Can You explain why *constuctor* injection is necessary in this case?
Two things are required. Something needs to have a @This declaration,
otherwise the state isn't brought into the composite.
Secondly, whatever does the mapping needs a reference to that private
mixin, primarily for performance reasons. Well, I guess an abstract method
would also work...
class PersonMixin extends DefaultAssociationStateDecorator
{
@This
private State state;
protected Object state()
{
return state;
}
}
> You could be running into some chicken-and-egg-problem. Could making the
> State interface static help?
Doh... interfaces are always static. As mentioned earlier, there is no
"bond" between the "interface State" and its containing class. The link
happens with the @This annotation on either a field or
parameter/constructor injection.
Niclas
> Den 08-11-2015 kl. 04:17 skrev Niclas Hedhman:
> > Gang,
> >
> > I tend to use private state a lot, in a hidden interface within the
> > composite. I end up writing,
> >
> > @Mixins( PersonMixin.class )
> > public interface Person
> > {
> > String name();
> > Person spouse();
> >
> > interface State
> > {
> > Property<String> name();
> > Association<Person> spouse();
> > }
> >
> > class PersonMixin
> > {
> > @This State state;
> >
> > public String name()
> > {
> > return state.name().get();
> > }
> >
> > public Person spouse()
> > {
> > return state.spouse().get();
> > }
> > }
> > }
> >
> >
> > I find this being too much boilerplate and have been thinking of
whether it
> > should be fixed. I am proposing that we create a "Decorator" (better
name?)
> > all the way into the API to support this.
> >
> > @Mixins( PersonMixin.class )
> > public interface Person
> > {
> > String name();
> > Person spouse();
> >
> > interface State
> > {
> > Property<String> name();
> > Association<Person> spouse();
> > }
> >
> > class PersonMixin extends DefaultAssociationStateDecorator
> > {
> > PersonMixin( @This State state )
> > {
> > super( state );
> > }
> > }
> > }
> >
> > But then, why not expand on this and support Spring-style
getter/setters as
> > well?
> >
> > @Mixins( PersonMixin.class )
> > public interface Person
> > {
> > String getName();
> > Person getSpouse();
> > void setSpouse( Spouse spouse );
> >
> > interface State
> > {
> > Property<String> name();
> > Association<Person> spouse();
> > }
> >
> > class PersonMixin extends SpringBeanAssociationStateDecorator
> > {
> > PersonMixin( @This State state )
> > {
> > super( state );
> > }
> > }
> > }
> >
> > It is a relatively simple implementation, quite efficient in terms of
> > execution, and the main question for me is where to put it;
> > a. Core API (my choice)
> > b. In a library
> > c. Keep it to myself.
> >
> > WDYT?
>
