Speaking of contexts:
does this enhanced module start to form a context ? Is the module the right
level of abstraction / size for a context ?
Or should we allow contexts of arbitrary sizes (big and small ones). I.e. the
scope where the additional roles of the
object are allowed / requested.
Is the smallest context the UoW and the biggest the application (or cluster of
applications) ?
Should we only allow concrete behaviour to be specified here or should it also
be possible to add Abilities == Roles ?
Lots of questions
Michael
Am 12.02.2009 2:42 Uhr, schrieb Michael Hunger:
> 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 feedbackI.
>
> 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
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
