Niclas Hedhman wrote:
On Wed, Aug 19, 2009 at 12:28 PM, Rickard Öberg<[email protected]> wrote:
so I would like to commit it anyway.
Go head, I will help you clean up the tests, samples, tutorials and
elsewhere that may fail now.
Alright, all is committed. I think I have fixed all the other stuff as
well, but if you can check too, that'd be great.
So, to summarize, here is what you can do now. From my own project, we
got a role for simply "giving stuff names", and it looks like this:
@Mixins(Describable.DescribableMixin.class)
public interface Describable
{
void describe(@MaxLength(50) String newDescription);
boolean hasDescription(String description);
String getDescription();
@Mixins(DescribableMixin.class)
interface DescribableState
{
@UseDefaults
Property<String> description();
@Event
void described(DomainEvent event, String description);
}
public abstract class DescribableMixin
implements Describable, DescribableState
{
public void describe(String newDescription)
{
described(CREATE, newDescription);
}
public boolean hasDescription(String description)
{
return description().get().equals(description);
}
public String getDescription()
{
return description().get();
}
// State
public void described(DomainEvent event, String description)
{
description().set(description);
}
}
}
---
The main point is that the mixin implements both the public and private
mixin interfaces, and is marked abstract so that it doesn't have to
implement the description() property. Not only can the mixin call
methods that it itself does not implement (such as description()), but
if it calls public methods they will be routed through the composite,
which in this case means that my concern that triggers on the @Event
annotation will be invoked when describe() calls described().
The above is the general pattern for entity roles that we are using now,
and it's working pretty well I think. The Event concern mentioned above
will create the DomainEvent for us so that described() will get an
actual event as parameter ("CREATE" is just a dummy object that we use
instead of "null"), that includes things like date of event, who invoked
it, on what object, etc., so that such things does not have to be
included as explicit parameters. Events can then be listened to by other
parts of the system, or other systems.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
