Niclas Hedhman wrote:
> Yes on both accounts. The 'current' event system is messy like nothing
> else, and I wonder if that is a symptom that this is harder than we
> think or just the regular Ball Of Mud entropy...
I tried doing this, but it became even more bizarre because the concerns
are declared at runtime, which causes runtime concern declarations to be
mixed with assembly time concerns... and it just becomes weird.
So I tried another approach: have a statically declared property
observer concern that is applied to all property methods. When invoked
it wraps the original property. The wrapper, which implements Property,
has a @Service injection to a PropertyObserverService where you can
register listeners.
When the concern is invoked, for any property, it hence notifies the
service, which in turn can notify any dynamically registered listeners.
The notification contains all the context for change, including the
entity, the original property, and the new value. With this the listener
can make intelligent things. Here's the notification method signature:
void propertyChanged( EntityComposite entity, Property property, Object
newValue )
If the listener is only interested in a particular property instance
then it can filter notifications based on the above. This filtering can
be put into an adapter for easy usage, like so:
PropertyObserverService observers = ...;
observers.addObserver( new PropertyObserverFilter(fooEntity,
fooEntity.property1(), new PropertyObserver()
{
public void propertyChanged( EntityComposite entity, Property
property, Object newValue )
{
System.out.println("Property "+property.qualifiedName()+" in
"+entity.identity().get()+" changed to "+newValue);
ok = true;
}
}));
The above will only output a message if the specific property in the
specific entity is changed. This pattern can be used for Swing bindings
so that when a property is bound to a Swing component you also register
an observer for that particular property. If the property is updated you
then update the Swing component showing it.
All of this can be done without any infrastructure in UnitOfWork. The
only "feature" used is Module Concerns.
With this approach it would also be easy to do similar for associations
and manyassociations, and you would get callbacks that are granular
enough to implement undo/redo functionality :-)
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
