2009/2/11 Rickard Öberg <[email protected]> > Hey, > > Niclas and I have today been discussing the "temptation" with being able > to add concerns and sideeffects which are not part of the Composite > declaration. Effectively these would be able to handle quite a lot of > the usecases which UoW state change notifications and vetoes were > supposed to handle. As already mentioned, the state change stuff messes > up UoW quite a bit, and for some usecases it is still not enough as it > is lacking detail in the events. > > The danger, of course, is that the ability to add these things "from > outside" gets us into the same messiness that AOP had with the > "pointcuts can add anything to anything, anywhere" deal. > > The proposal we came up with, which we can sort of live with and also > makes sense, is that it is possible to declare concerns and sideeffects > using the fluent API for composite declarations in ModuleAssembly. This > makes all assignments explicit, and there's no way that a generic > declaration can "seep" into places it wasn't supposed to go into. Example: > assemble(ModuleAssembly module) > { > > module.addEntities(MyEntity.class,AnotherEntity.class).withConcerns(SomeConcern.class, > AnotherConcern.class).withSideEffects(SomeSideEffect.class); > } > --- > The idea here is that there *is* a division between the developer > responsibilities and the assembler/deployer responsibilities, and the > above would cater to the latter. > > The end result will still be visible by using the visualizer, which will > show the combination of the concerns from the Composite and those from > the assembly. > > What do you guys think about this? Does it seem like a decent compromise? >
+1 sounds reasonable to me /Rickard > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev > -- Cheers, Stuart
_______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
