cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: [Fwd: cvs commit: cocoon-2.1/src/java/org/apache/cocoon/servlet]
Date Sun, 16 Mar 2003 21:47:13 GMT

Stefano Mazzocchi wrote, On 16/03/2003 20.50:
> Nicola Ken Barozzi wrote:
>> Thanks :-)
> You are welcome.
> Nico, I must be honest with you, the Notifying classes well... hmmm, how 
> to say this... ehmmm... all right: I don't like them.


> My feeling is that they are too complex for the easy thing they do. They 
> are somewhat over-objectified.

Could be.

> I know you had plans to improve them (I saw the comments inside and the 
> skeleton of what you want to do) but I just think that you're simply 
> trying to do too many things, resulting in such mess that is hard to 
> understand who handles what and why.

The mess is due to lack of documentation. I suck for this.

> I'm not suggesting to remove them, but I'm suggesting to simplify them 
> by a great deal and I would like you to be involved because you know all 
> the pieces of the puzzle.
> This is not so critical so can be postponed at post-2.1 release, but 
> this will have to be done and I would like to know your comments about 
> this.

Stefano, it's kinda wierd how you wrote this letter... because you 
(correctly) know that I've been so... ahem... touchy on this issue ;-)

Well, the fact is that they were written by me some years ago, after lot 
of thinking, but with an eye to a certain "perfect" notification system, 
rather than to solve the simple problem. Then the later modifications 
made them better but kept the same goal.

Now this is clear, because *no* feature that the system makes available 
has ever been used. Everyone, please witness this: if you do more than 
is necessary beforehand, most probably it will be *never* used.

Before replying, I have looked at the code, and it's not that "complex" 
or overengineered to me, but that's probably because you have a 
different view of what it should do... anyway, a couple of things can be 
done easily, like switching to a full concrete implementation instead of 
using interfaces.  -> zap, never used -> zap, never used    -> zap, never used -> Notification    -> NotificationBuilder

So the result would be:

Notification  (what to notify)
NotificationBuilder (the Notification creator)
Notifier (the Notification "sender")

Which is much simpler, and loses all extensibility, which has never been 

We could also merge Notification with NotificationBuilder and have simply


but then we could also have simply a


that can both create itself and send itself, but I'd prefer the three 
class version.

Anyway, this is waht I came up to now. Dunno if it makes sense, maybe it 
solves the wrong problem, what do you think?

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message