> This last one is something that needs to be explored to find out whether > it's useful or not. Basically, an EntityComposite can be cast to another > EntityComposite type if the latter is a subtype of the first. This can > be used to extend the mixins and properties of the Entity, but can also > be used to replace implementations of existing mixin types in the > EntityComposite. If this is a good way to change validation rules or not > I am not sure yet, but it's a possibility.
I think this is where the role specific aspect comes into play. An entity in another state plays another role. So having a kind of state behaviour mixin that can be changed would be one solution. I'd rather like to have the entity as a private implementation and just offer role specific views (where role can also depend on state) to the outside. So you can not only limit operations on data depending on role but have a differnent type/view on the entity with perhaps different mixins attached. So perhaps the core entity is a private part of the composite and only the role/state specific interfaces publish the information neccessary or allowed. Michael _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
