[dev] Notifications and embedded hyperlinks

[Jan Schneider]

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.

Jan.

--
http://www.horde.org - The Horde Project
http://www.ammma.de - Neue Wege des Lernens
http://www.tip4all.de - Deine private Tippgemeinschaft