[dev] Notification question

[Hans Lellelid]

>
>
>>The one question I had for this list is whether there is any design
>>reason why $message in the $notification->push() method would need to be
>>a string.  I would like to push an array -- e.g. with the thread_id that
>>was updated etc. -- and while there doesn't seem to be anything in the
>>Notification class that would prevent this, the assumption does seem to
>>be that $message is a string -- and I'm wondering if there is any larger
>>picture in Horde that I'm missing.  (I don't want to misuse the API so
>>that my app would be incompatible w/ future releases.)
>>    
>>
>
>We'd have to modify the API so that the current listeners handle things
>correctly, but I don't think that'd be a problem. In fact, I'd be in favor
>of pushing around Notification_Event objects instead of strings, so that we
>can have other kinds of info easily in there, and listeners can only take
>what they want.
>
Ahh -- yes, a Notification_Event object that could be extended by 
applications would fit in well with the Notification/Listener model. 
 Would you need to create a new object, then, for every ->push() call? 
In many cases (e.g. 'status') the simple text message works really well.

// seems a little excessive
$event = new Notification_Event();
$event->setMessage(_("Your password was updated successfully."));
$notification->push($event, 'horde.success');

Could push() be passed paramters of different types?  -- or maybe could 
$message param type be set when attach()ing a listener or returned by a 
method of listener class itself...(analogous to ->handles(), for example)?

My original thinking was that listeners could set up their own 
expectations for the type of the $message parameter -- i.e. the notify() 
method would assume (or test) that messages passed to it were of a given 
type (string, array, object).  This does seem a little sloppy, though -- 
and using objects would certainly account for all needed flexibility.

Anyway, am curious to know what you think on that.  I'd be interested in 
(and would obviously benefit from) implementing this.

>Do share the new listeners that you're working on with us!
>
of course :-) Most of my classes will probably be pretty project- and 
app-specific (very customized), but I'm certainly very happy to help 
contribute anything generic -- and to the generic code that will make 
this possible, etc.

Cheers,
Hans
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4461 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.horde.org/archives/dev/attachments/20030110/e032d7ff/smime.bin