Add support for the HTML5 Notification API

[adam-waldenberg]

Add support for the Notification API.

Either a seperate or a sub-component is probably the way to go .. To throw some ideas around, it would be cool if something like this was doable;

<o:messages>
    <o:notification icon="#{bean.notificationImage}" action="#{controller.onClick}/>
</o:messages>

... or this,

<o:messages>
    <o:notification icon="#{bean.notificationImage}">
        <o:notificationCommandButton title="Exit" action="#{controller.onExit}">
        <o:notificationCommandButton title="Enter" action="#{controller.onEnter}">
        <o:notificationCommandButton title="Javascript" onclick="...">
    </o:notification>
</o:messages>

... or this,

<o:messages>
    <o:notification icon="#{bean.notificationImage}" onclick="... " onclose="..."
                    onerror="..." onshow="..."/>
</o:messages>

Here are some common use cases:
https://web-push-book.gauntface.com/demos/notification-examples/
https://developer.mozilla.org/en-US/docs/Web/API/Notifications_API/Using_the_Notifications_API

[melloware]

@adam-waldenberg So your thought is to intercept FacesMessages for these notifications? I am wondering if it should just be a complete separate component and not use FacesMessages?

[adam-waldenberg]

@melloware Personally, I definitely want something that integrates with FacesMessages.

Doing it as a sub-component would allow to show notifications "the usual way" and at the same time also automatically send them to the notification API. It could also take advantage of what's already implemented in o:messages. It's probably a little clunky though - considering notifications are more like a "growl".

Another way to go about it could be to do a separate component and just revert to a growl-type kind of notification if permissions to the notification API are not given.

[BalusC]

Interesting. Will look for 3.4.

[jepsar]

@adam-waldenberg I believe notifications are only useful when then page is not visible. In that case FacesMessages wouldn't be my first choice as they are bound to a request. I think pushing them over a websocket would be more useful.

[adam-waldenberg]

@jepsar I dont agree. Any custom solution like that would require a non-standard way of pushing notifications (non standard as in outside the scope of how things usually function in JSF). A normal way to trigger updates on a page on websocket notifications is often something like this (when this happens the browser is usually not visible);

<f:websocket channel="channel" scope="scope">
    <f:ajax event="event" listener="#{bean.listener}" render="target" />
</f:websocket>

Which would obviously trigger a refresh on the section that's being updated and also a request - where there are usually FacesMessages being returned for notifications and errors. This could come from the listener or some other place. I would also like to mention that the above construct (or a variation of it) is probably the most common way f:socket is used in enterprise applications.

There's obviously a use case for supporting a more direct method - but for JSF, not supporting FacesMessages doesn't make any sense.

[jepsar]

@adam-waldenberg Sure, you could do it like that, but a FacesMessage doesn't have all the properties you could use in a browser notification. It will work if you don't care about setting a custom icon per message for example. Another issue will be implementing events. How would you know which message was clicked for example?

I would just take the message object pushed to the socket and process it using JavaScript. There you can determine if the browser is in view. If it is you could update the messages component / growl, if it's not you could send a browser notification.

[adam-waldenberg]

@jepsar I already covered an example on how to handle events when I started this issue (though I'm not saying my particular example would be the optimal one). It doesnt have to be part of the FacesMessage if its part of the component that handles the message.The same goes for icons. If you want to change the icon, just share a different one via the backing value and let the component fetch the icon on request. Each time a new message arrives you can share a different icon.

If you take advantage of normal JSF design principles here - the solution is quite simple.

[BalusC]

FYI: I played around it last year but in the end it had a few hard requirements and the event behavior was awkwardly not consistent across browsers. I didn't have the impression I could build a stable JSF component around it.

One of the hard requirements was a service worker which I eventually kicked off with a basic implementation via https://showcase.omnifaces.org/resourcehandlers/PWAResourceHandler introduced in 3.7. This can then easily be expanded to cover this new notification feature. I'll the upcoming year take a second look at the browser state.