Michael Hunger wrote: > Ok, thats the way I would have done it as well :) > Looking forward to your code :)
The main improvement I would consider is that if a Property is a ValueComposite (to be defined), then it is created as a subnode instead of a property on the Entity-node, and then the ValueComposite Properties are added to that node instead. Nice and hierarchical. > Btw. with all those new entity stores: Would it be sensible to have a default > implementation for those blob - > entitystores with basic handling for properties/assocs, perhaps having a sax > like callback interface for each prop/assoc > in the abstract store? (Besides AbstractEntityStoreMixin) AbstractEntityStoreMixin will be renamed to EntityTypeRegistryMixin so that it is clear what it does and doesn't do. It will also be possible to use it in an EntityStore not by subclassing it, but rather using it as a separate Mixin accessed through "@This EntityStore registry". Much cleaner. About the handling of props/assocs, yes, that can probably be extracted out into helper classes. It's just a matter of finding the patterns and refactoring it. So far there are already three Fragments for EntityStore implementations (Concurrent change concern, EntityStore change notification SideEffect and the EntityTypeRegistryMixin). I think more and more functionality will be extracted out into Fragments as we see patterns that are recurring in all the implementations. Which, after all, is one of the big supposed bonuses with COP in the first place :-) /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
