On 8/19/11 06:46 , Marc Grue wrote:
- Are @Structure elements etc. injected with a ServiceImporter in the
assembly or something like that?
@Structure gives composites access to Qi4j-specific stuff like
Application, Layer, Module, etc. In current Qi4j you can also inject
things like "ObjectBuilderFactory" but those things are going away in
v2.0 in favor of putting all those methods in Module itself.
- If you can't inject vbf, uowf etc
into the Context, wouldn't the inner classes just be able to access
those
Right now the Context can be easily injected with anything, as it's just
a regular object/class. Inner classes are trickier since they need to be
instantiated within the Context. So far I can only think of using manual
"new FooRole()" calls in the context, rather than Qi4j instantiation.
Maybe it would be possible to fix this though. Have to find out.
- How does your Role class look? That's were self and
bind(object) are defined, right? Is there a self() method also? (2nd
last line)
My current Role code looks like this:
public class Role<T>
{
// Self reference to the bound Data object
protected T self;
public Role()
{
}
public Role(T self)
{
this.self = self;
}
public void bind(T newSelf)
{
self = newSelf;
}
public T self()
{
return this.self;
}
}
- I guess it's seldom that you would need different
implementations of a Role (mixins for an interface, the old way) -
Can you give an example of method name clashing with the old way?
Sure, you could have two mixins that both allow updates of its inner
state. Without some kind of qualifying part to their names you might
call them "update(String)" and "update(String)", which would make it
impossible to work considering how Java works. With the DCI roles as
shown they would be trivially separate as the Roles are wrappers rather
than mixins. With this approach it would essentially be possible to do
it without Qi4j altogether. That being said, I still think it's valuable
to use mixins for the Data, to keep different aspects of an Entity
apart, like Description and ACL's.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
