Quoting Rickard Öberg <[email protected]>:
This is the responsibility of the system code that gathers the
selected objects and instantiates the context. If the constructor in
the context is used it is very simple (put right object in right
parameter), whereas with injection the injector has to deal with it.
The context only holds the selection and allows interactions to be
fired off with that selection as a given rather than as parameters.
In Streamflow this is done by the REST API. In an upcoming version I
have completely separated the lookup/mapping of objects to roles and
the actual context. Right now these two are mixed, which is not nice.
Ahh, I see. I guess that's a working strategy, since you haven't
probably encountered any problems which would stop development. I hope
this same principle holds in any general case (something else than web
app), it seems to put a lot of responsibility for injector. Because,
in that case, injector has to know the rule that tells that for
context X, for role Y, in case there are many candidates for Y, pick
specific one of them. The logic in selecting this one has to be in
injector, or expressed by some rule to injector.
See your point, but it still sounds a bit weird to bring in a DCI
framework to get access to Typeable, if you see what I mean.
I think I could either:
1. Drop the 'context' sub-package in LWDCI, and possibly rename the
project to something else, non-DCI related.
or
2. Drop the 'context'-sub-package, and add RoleMap from streamflow. It
seems that all contexts always have RoleMaps, so it would be nice to
have some generic implementation for it, and it would make framework a
little more worthy DCI-wise.
WDYT?
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
