Consider deprecating and dropping h:form prependId

[BalusC]

Historically, h:form prependId=false was introduced in JSF 1.2 as sort of patch in order to be able to submit to j_security_check using a JSF form. Since introduction of programmatic login API HttpServletRequest#login() in Servlet 3.0, released at the same time as JSF 2.0, the prependId=false has become unnecessary as people can just use HttpServletRequest#login() instead of submitting to j_security_check. Moreover using prependId=false breaks the in JSF 2.0 introduced f:ajax and composite components as well as the in JSF 2.3 introduced f:websocket because it causes the findComponent to not anymore work within naming containers, see also among others #573.

These days, people don't anymore use h:form prependId=false specifically to be able to submit to j_security_check, but they abuse prependId=false generally to be able to use ids in CSS selectors without the need to escape them. But these people actually need to be re-educated about CSS best practices so they don't anymore need ids in CSS selectors for non-unique elements/components, see also among others https://stackoverflow.com/a/5882502.

All in all, using h:form prependId=false in JSF 2.x or newer is a red flag and is always discommended. We should deprecate the attribute and eventually remove it so people won't anymore fall into the trap. Do note that this attribute is absent in all naming container components other than UIForm and the community never reasonably requested for standardizing it in NamingContainer.

[melloware]

I still use this for PFE credit card component. There was a limitation in the JS library where the ids had to be exact like number, expiry, etc.

It only works with prependID false

[BalusC]

Yeah I remember a similar case with a postcode/address autocomplete JS library. I just forked and rewrote it to allow specifying client IDs as option rather than adhering to predefined client IDs. Tight coupled libraries are bad. If it's public and open for support, post a issue / feature request. Else probably better look for another one allowing that option.

Note that it would still fail if your form is in turn nested in another naming container such as p:tabView. Or even when used in a (Liferay) Portlet where the UIViewRoot is a NamingContainer.

[melloware]

You are right i might look into just fixing the credit card JS which isn't really receiving updates anyway these days!

[BalusC]

You are right i might look into just fixing the credit card JS which isn't really receiving updates anyway these days!

It would probably be cool if you simply pass client ID of a common parent component and let the script figure out it based on autocomplete="..." values which are already predefined by standard spec ;)

[volosied]

This seems fine to me. Although some of our tests use prependId=false, but they can be refactored.

Would the deprecation be targeted for 5.0 and removed in 6.0?

[BalusC]

Yeah, deprecate as early as possible. Along with a WARN log when it's being used to make the developer aware.