On 2010-05-29 19.29, Marc Grue wrote:
I'm looking at ConcernOf<T> and have looked into its use in Streamflow. Can you help me understand why the following entities (that all use the ConcernOf<Removable>) extend Removable in different ways, like casetype.ResolutionEntity [no extension to Removable]
ResolutionEntity extends Resolution which extends Removable. ResolutionEntity should have extended Removable.Data though, which was a bug that it didn't.
In effect, however, it *will* extend Removable.Data since the Removable.Mixin references it. Having ResolutionEntity not extend Removable.Data only makes it hard to query for resolutions that are removed(or not).
label.LabelEntity extends Removable.Data
and LabelEntity extends Label which extends Removable.
project.ProjectEntity extends Removable, Removable.Data
ProjectEntity extends Project which extends Removable. I've removed Removable from ProjectEntity now. It was an unnecessary duplication.
What does the extensions to Removable/Removable.Data add that you don't get from RemovableConcern alone? Or, what are the differences between the three "scenarios" above?
They are the same! The LabelEntity example is the most "correct", and I have changed the other two to the same style now.
I should have written a test to confirm this, but is it correct that you can't reference next.uowf in your RemovableConcern implementations since you have reinjected uowf there? So, you can execute next.someMethodInSomeType() in a ConcernOf<SomeType> but not point to next.someFieldInSomeType, or am I wrong?
If you have ConcernOf<SomeType>, then you can only call methods on SomeType on "next". The idea is to continue the invocation chain, and you should not (cannot) make any assumptions about what comes next, in terms of fields or other methods.
For other newcomers, I can warmly recommend studying the tests in qi4j-core-runtime and then search for and study real-world usages in the Streamflow project!
I agree :-) But at the same time, like in this case, keep in mind that we are also continuously discovering better ways to do things, and the entire codebase might not do the same thing equally, if we forgot to change all the places.
/Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
