This sounds great.
I was always wary of the listener stuff because this is on one hand very
unspecific and not necessarily type safe
and on the other hand has some memory leakage problems.
I would also propose the declaration at assembly time. This makes the stuff
explicit.
Perhaps we'd like to be able
to restrict the available SideEfffects / Concerns with AppliesTo Filters at the
Entity, where the developer could
disallow (include/exclude) certain stuff from its composites?
Visualizing it is another great benefit. The lazy loading of the mixins also
helps in speeding up things. And having
asynchronous sideeffects there is a great benefit for e.g. user feedback.
This could not only applied to the UI part but also in other parts of the
application where a "Context" (perhaps this is
already what we are talking about here at the assembly level !!!! ) adds
certain concerns/sideffects to the entities in
place.
What would be nice is adding the stuff also in a more general way. E.g. I want
to add the stuff to all composites
implementing a certain interface or to all services or whatever. So there
filters would come handy. That would reduce
the tedious and manual task of adding the same stuff to (e.g. all entity
composites that shall be used with this
additional functionality). Or is this tooo magic AOP like ?
What about the mixins necessary for the SideEffects/Concerns. Besides having
those that are declared at the SE/C
interfaces. If I'd like to have slightly different mixin implementations, where
would I declare them?
Great work
Michael
Am 11.02.2009 14:58 Uhr, schrieb Rickard Öberg:
> 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?
>
> /Rickard
>
> _______________________________________________
> 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
