I like it! The whole cargo.origin().get() never sat right with me. A
couple of questions:
1) Do you really need the @AssociationField in the CargoMixin? Seems like
you already have all the information you need available already.
2) I'm not in love with the builder methods. Maybe something like
EntityBuilder<Cargo> builder = ...;
Cargo cargoTemplate = builder.template();
builder.set( cargoTemplate.origin() ).to( origin );
builder.set( cargoTemplate.destination() ).to( destination );
would be more natural?
Rich
On Fri, Oct 24, 2008 at 9:29 AM, Edward Yakop <[EMAIL PROTECTED]>wrote:
> Hi,
>
> I think we need to introduce another mechanism to declare property and
> association.
> Let's look at dddsample and try to implement Cargo model.
>
> If I want to retain exactly the same Cargo interface:
> <code>
> public interface Cargo
> {
> Location origin();
>
> Location destination();
>
> void changeDestination( @NotNull Location newDestination );
>
> ...
> }
> </code>
>
> To make Cargo persistable, I need to create a mixin type.
> <code>
> public interface CargoState
> {
> // Unfortunately the name has to be done this way, because our
> entity will implement both CargoState and Cargo
> Association<Location> originAssociation();
> Association<Location> destinationAssociation();
> }
> </code>
>
> And the entity
> <code>
> @Mixins( CargoEntity.CargoMixin.class )
> public interface CargoEntity extends Cargo, CargoState, EntityComposite
> {
> class CargoMixin implements CargoEntity
> {
> public final Location origin()
> {
> return orginAssociation.get();
> }
>
> Location destination()
> {
> return destinationAssociation.get();
> }
>
> public void changeDestination( @NotNull Location newDestination )
> {
> return destinationAssociation.set( newDestination );
> }
> }
> }
> </code>
>
> If I have to do this very same thing for every model. I might as well
> forget about my productivity.
> Adding/Removing property and association is definitely painfull.
>
> But, if we support this
> <code>
> public interface Cargo
> {
> @Association
> Location origin();
>
> @Association
> Location destination();
>
> void changeDestination( @NotNull Location newDestination );
>
> ...
> }
> </code>
>
> We can reduce the entity implementation to
> <code>
> @Mixins( CargoEntity.CargoMixin.class )
> public interface CargoEntity extends Cargo, EntityComposite
> {
> class CargoMixin implements CargoEntity
> {
> @AssociationField private Association<Location> destination;
>
> public void changeDestination( @NotNull Location newDestination )
> {
> return destination.set( newDestination );
> }
> }
> }
> </code>
> I would not need to care implementing Cargo#origin() and
> Cargo#association().
> Because I already put a @Association annotation.
>
> If I want to implement concern/side effect on the setters or getters
> of these association,
> this becomes very trivial to do.
>
> How about creational?
>
> EntityBuilder<Cargo> builder = ...;
> Cargo cargoTemplate = builder.template();
> builder.initialize( cargoTemplate.origin() ).set( origin );
> builder.initialize( cargoTemplate.destination() ).set( destination );
>
> Query would be done in similar manner.
>
> wdyt?
>
> Regards,
> Edward Yakop
>
> _______________________________________________
> qi4j-dev mailing list
> [email protected]
> http://lists.ops4j.org/mailman/listinfo/qi4j-dev
>
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
