Enhance UIInput events with HTML5 like oninput

[tandraschko]

https://github.com/primefaces/primefaces/issues/1493

[codylerum]

This is definitely something that is holding back JSF development when compared to direct HTML.

[tandraschko]

I analyzed it and we need the following new attributes:

all elements

• onwheel
• ondrag
• ondragend
• ondragenter
• ondragleave
• ondragover
• ondragstart
• ondrop
• onscroll
• oncontextmenu
• oncut
• oncopy
• onpaste

body

• onafterprint
• onbeforeprint
• onbeforeunload
• onerror
• onhashchange
• onmessage
• onoffline
• ononline
• onpagehide
• onpageshow
• onpopstate
• onresize
• onstorage
• onunload

inputText, inputTextArea, inputSecret (here we also need to add this to the behavior events)

• oninput
• oninvalid

form

• onreset
• novalidate

[melloware]

This looks good to me. And yes this feature gets asked for over the years a lot on PF. I see you are missing a few though like..

• oncut
• oncopy
• onpaste
• oncontextmenu
• onsearch

[tandraschko]

@melloware adjusted it but onsearch is currently only in chrome?!

[melloware]

Understood. Probably not very useful anyway.

[BalusC]

https://developer.mozilla.org/en-US/docs/Web/API/GlobalEventHandlers https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement#events

[BalusC]

I'm a bit torn on this. The list is even longer on https://html.spec.whatwg.org/multipage/webappapis.html#event-handlers-on-elements,-document-objects,-and-window-objects The list seems to be able to grow infinitely. There are currently in total more than 60 officially specified on* attributes for "all elements". The average Faces component has currently ~12 on* attributes, all dated from the HTML4 era. There are currently 23 Faces components thus each needing ~48 more attributes.

I'm not going to manually add more than 1000 attributes every time. This is not DRY and not long-term-maintainable.

Moreover, this doesn't really advocate "unobtrusive JavaScript" (https://en.wikipedia.org/wiki/Unobtrusive_JavaScript#Separation_of_behavior_from_markup).

I'm much more tempted to let Faces automatically treat every single attribute whose name starts with on as an automatic passthrough attribute if the associated event is known, rather than explicitly registering them as a copypasted <attribute> entry in some taglib XML file and as yet another getter/setter pair in some component class.

Internally, the existing HTML components and renderers already do absolutely nothing with them, they're all already just "passed through" without additional logic. We can at most maintain a (configureable?) list of all allowed event names per component type HtmlBody/UIOutput/UIInput/etc so that associated on* attributes may to be passed through, including unknown ones but at least log a dev stage warning on unknown ones. This way we can get rid of the associated getter/setter and taglib.xml boilerplate on them. If needed the renderer can still get/set the attribute via UIComponent#getAttributes().

For example HtmlBody has currently already this constant returned by its UIComponent#getEventNames():

    private static final Collection<String> EVENT_NAMES = Collections.unmodifiableCollection(
            Arrays.asList("click", "dblclick", "keydown", "keypress", "keyup", "load", "mousedown", "mousemove", "mouseout", "mouseover", "mouseup", "unload"));

This could be extended via some configuration file (context param?) and this could be consulted by the renderer while rendering an encountered on* attribute.

[codylerum]

That would seem like the ideal situation so that JSF developers don't end up waiting for support of newly added events.

Do we even need to warn if the attribute isn't known?

[BalusC]

Do we even need to warn if the attribute isn't known?

Typos would otherwise slip through and devs would then blame Faces not for being helpful on this. New ones could if necessary be added via some configuration file (e.g. web.xml param) so that the warning will be suppressed. The internal list of known event names behind UIComponent#getEventNames() can be synced to HTML spec every new Faces (minor) version.

[codylerum]

Sure, that would work. Just being a simple list it should be easy to update and less of an issue with a more predictable release cadence going forward.

[tandraschko]

i wonder whats actually bad of using passthrough attributes for all native html attributes? JSF could remove 80% of the attributes probably and is more flexible for the future

and even e.g. PrimeFaces modifies onclick of some components, it can grap it from passthrough attributes instead of normal attributes

especially @BalusC @arjantijms

[tandraschko]

the only thing comes in my mind is the migration part... users have to change "onclick" to "pt:onclick" maybe we can automatically convert this, too

[BalusC]

I made a start, with this PR Mojarra renders every on* attribute as long as it's covered by ClientBehaviorHolder#getEventNames().

[BalusC]

Moved 4.1 to 5.0 as this is a rather big change.

[BalusC]

I came up with the Faces spec change: https://github.com/eclipse-ee4j/mojarra/commit/7236717db399cb08aeb23331c5f16d83911e8913#diff-1cf448409ac10f68d18e8dc1e903fa0e0167555822784a028a5c53afd489a149R211 How about this, @tandraschko ?

[tandraschko]

@BalusC Could we first go trough the 4.1 issue list and decide what do with them all, before working on 5.0 stuff? Also need feedback about #1584

i will comment your PR on mojarra later