[dev] Notifications and embedded hyperlinks

[Michael M Slusarz]

Quoting Jan Schneider <jan at horde.org>:

> Zitat von Jon Parise <jon at horde.org>:
>
>> I've been toying with the idea of modifying the Notification package
>> to support the notion of embedded hyperlinks (or other markup).  My
>> specific use case involves embedded a link to the Nag edit page when a
>> new task is created from within IMP.
>>
>> The current 'status' listener calls htmlspecialchars() on the message
>> text.  This prevents HTML markup from being included in the current
>> implementation, so something needs to change to support this.
>>
>> Assuming everyone agrees this is a good idea, I've come up with these
>> possible solutions:
>>
>> 1. Allow markup to be included in the existing notification messages.
>>
>>     This would involve removing htmlspecialchars() from the 'status'
>>     listener.  An caller that might need the htmlspecialchars()
>>     behavior will have to call it directly before the event is pushed
>>     into the notification system.
>>
>>     Also, not all listeners may be able to handle embedded markup.
>>
>> 2. Introduce a new parameter -- $flags -- to the Notification::push()
>>    call.  A new NOTIFICATION_ALLOW_MARKUP flag will be introduced that
>>    allow the listeners to "do the right thing" with the message text
>>    when it comes time to render it.
>>
>>     This approach involves touching a lot of the Notification code.
>>     It's a one-time hit because the $flags field is generic enough to
>>     support additional flags in the future.  This will still result in
>>     listener-specific behavior, however: some listeners may be able to
>>     render the markup while others will just convert it to entities or
>>     strip it out entirely.
>>
>> 3. Introduce a new notification type: horde.message.markup (or
>>    something) that listeners can choose to handle.
>>
>>     This involves not changes o the Notification API.  The handlers
>>     can be updated to support this new type individually.  Any
>>     additional encoding is the responsibility of the caller.  The
>>     downside is that, if the current listener chooses not to handle
>>     this new type, the event will essentially be lost.
>>
>> Opinions?
>
> I'm for 4: Use special markup (e.g. wiki or reST style) to include links
> into the message. They are human readable with listeners that don't support
> them and we'd only have to change the status listener to create a real link
> from them.

FWIW, I'm for #2.  It is nice not to have to manually call htmlspecialchars()
every time you have an event, and our other handlers seem to be more event
types (warning, error, etc.) rather than formatting instructions per se.

#4 would be OK also, but much slower for someone, like me, who have no 
idea what
the reST markups are (although I hear i is easy to learn).

michael

______________________________________________
Michael Slusarz [slusarz at bigworm.colorado.edu]
The University of Colorado at Boulder