On 10/6/11 01:33 , Marc Grue wrote:
Hi all,
Finally ported the DDD Sample application to DCI using Qi4j and Wicket:
Blog: http://marcgrue.com/dci/dci-sample
Repo: https://github.com/DCI/dci-sample/
Zip: http://marcgrue.com/uploads/dci-sample.zip
Run Start8082 in version b and point a browser to localhost:8082 to start
shipping cargos with a DCI backend!
Looking forward to hear your thoughts...
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?
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
