Hi Rickard,
THANKS!!! :-) Really glad you liked it so far!
I don't have any strong opinion on how the Context gets to know what Data
objects can play its Roles. Maybe it's a matter of perspective. If we se the
Context layer as an encapsulated conceptual entity, then RoleMaps are part of
that and thus in a way not "outside of the context" - of course outside the
individual Contexts, but conceptually not outside the Context implementations -
on a conceptual level. That's at least one way to see it (as I did with the
current code). Maybe that's a naive way of seeing it that could create
problems further down the road. But it hasn't with this level of complexity. We
need a much more complex example! ;-)
Apart from the reasoning benefit of an explicit RoleMap where you can see "who
plays what", there might even be another benefit of this approach; that you
could bootstrap alternative RoleMaps! Haven't thought this through, but imagine
having a project with "Summer-Role-Mapping" and "Winter-Role-Mapping". Scary,
but also tickling... :-)
I guess there's also the core goal of DCI to cinsider of making the code as
understandable as possible. In that respect, any magic coupling in background
might make it more indirect to reason of a specific use case or a set of use
cases. It's for instance obvious from the CargoRoleMap that the Cargo is
involved in all the inspection sub-use cases:
public interface CargoRoleMap
extends CargoEntity,
RegisterNewDestination.CargoInspectorRole,
AssignCargoToRoute.CargoInspectorRole,
DeriveUpdatedRouteSpecification.CargoInspectorRole,
InspectCargoDeliveryStatus.DeliveryInspectorRole,
InspectUnhandledCargo.DeliveryInspectorRole,
InspectReceivedCargo.DeliveryInspectorRole,
InspectLoadedCargo.DeliveryInspectorRole,
InspectUnloadedCargo.DeliveryInspectorRole,
InspectArrivedCargo.DeliveryInspectorRole,
InspectCargoInCustoms.DeliveryInspectorRole,
InspectClaimedCargo.DeliveryInspectorRole
{
}
I think this is a valuable information from a birds perspective of handling
monitoring in the system. Then you can say: "Ah, it's clearly the Cargo that is
involved in all the events (Receiving, Loading, Unloading etc). If we had magic
in the background automatically assigning Cargo to the different event-handling
Roles, then we would loose this overall perspective. We wouldn't be able to
tell from one Context what event-Roles the Cargo plays in other Contexts. So I
guess I'm leaning towards to keep the current RoleMap and seeing it as a
semantic part of the DCI eco-system.
On the other hand it would be very interesting to see some of your suggestions
in action too!! There might be other benefits that we haven't thought of yet!
If I could get your help to make some prototype of one or more of your
suggestions below , I would be happy to play around with it in a version c/d of
the sample.
Cheers,
Marc
On 2011-10-06, at 11.42, Rickard Öberg wrote:
> I've been thinking about how to do the most tricky part about DCI, i.e. the
> assignment of the roles to the object, a little bit easier. Currently you
> have to explicitly create a RoleMap entity subtype or use wrappers, but that
> either exposes the roles outside of the context (they are supposed to be
> implementation details), or gives us the object schizophrenia issue.
>
> One possible option is to use the CompositeInstance.newProxy(type), and
> somehow allow type to *not* be preregistered, i.e. we can allow types to be
> added on the fly.
>
> Another is to use the ClassScanner facility, which allows for classpath
> scanning, and make it possible to automatically register the types in
> bootstrap. Example:
> public class ProfileAdminContext
> extends Context
> {
> Profile profile;
>
> public void bind(User user)
> {
> // "bind" uses CompositeInstance.newProxy(type)
> profile = bind(user, Profile.class);
> }
>
> interface Profile
> {
> class Mixin implements Profile
> {
> // This triggers that Profile is added as type to
> // any Entity that extends User interface
> @This User user;
> }
> }
> }
> ---
> This way the Role Profile stays an implementation detail.
>
> OR you might conversely say that while Roles should be an implementation
> detail, it *is* useful to have one place where you can easily see "who plays
> what", and that the "leaking" of those roles is actually useful.
>
> Now I'm torn.
>
> Marc, any opinion on this?
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
