search

jakartaee / faces

Jakarta Faces
Other
102 stars 54 forks source link

Enhance UIInput events with HTML5 like oninput #1507

Open tandraschko opened 4 years ago

tandraschko commented 4 years ago

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

codylerum commented 3 years ago

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

tandraschko commented 3 years ago

I analyzed it and we need the following new attributes:

all elements

body

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

form

melloware commented 3 years ago

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..

tandraschko commented 3 years ago

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

melloware commented 3 years ago

Understood. Probably not very useful anyway.

BalusC commented 3 years ago

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

BalusC commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 11 months ago

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

BalusC commented 11 months ago

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

BalusC commented 10 months ago

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

tandraschko commented 10 months ago

@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

BalusC commented 2 weeks ago

PRs are ready:

Next steps: