is from the
design phase and lists the reasons:
- type safety
- check mechanism to detect missing translations
- check mechanism to make sure all necessary parameters are really dealt
with, especially when calling the same event from multiple places.

I concede that overall the whole thing might look complex, but the end
result makes for quite clean code on the message production side.

Adding a new event isn't a big deal at all:
1. Add a new method to the EventProducer interface
2. Run the "resourcegen" task to update the model and translations
3. Fill in the translation

I believe the whole thing worked out quite nicely. Only recently did I
have a chance to make use of the event subsystem on a project where I
needed to detect certain layout problems. That was easily done and works
nicely. I sometimes think this whole mechanism would even warrant it own
Apache Commons subproject.

Design discussions:


On 22.10.2009 21:12:38 Simon Pepping wrote:
> Producing and sending an event is simple enough. But why should I go
> through the dynamic proxy, with an EventProducer interface and event
> model, instead of simply produce and send the event? This is the part
> that makes producing and sending a new type of event difficult to
> understand for me.
> Simon
> -- 
> Simon Pepping
> home page:

Jeremias Maerki

Reply via email to