Faces 4.0: add <h:inputText type>

[BalusC]

Add new attribute <h:inputText type> to allow HTML5 types such as

• email
• search
• tel
• url
• number (along with min, max and step attributes)
• range (along with min, max and step attributes)
• datetime-local
• month
• time
• week
• date
• color

https://developer.mozilla.org/en-US/docs/Learn/Forms/HTML5_input_types

NOTE: API may not validate/reject unknown ones as they are essentially extensible. Probably at most in dev stage log a warning when types are used for which a different standard component should be preferred such as secret, submit, file, hidden, checkbox and radio.

Currently already possible and working fine with help of passthrough attributes. But it's better and cleaner if it's directly supported by API.

Moreover, it would particularly on number/range based inputs be totally awesome if any minimum and maximum attribute of any attached <f:validateXxxRange> is consulted during render so that it's automatically rendered as min and max attributes.

[tandraschko]

i think we really have to think about this in general. Its very simliar to #1507

Should we continue to always manually add those attributes/events? or should we maybe accept all attributes and render them as passthrought.
Sure, taglib and IDE completion is the problem then.

[BalusC]

It's not the same.

Current ticket is basically:

• add type attribute to <h:inputText> (only one attribute! so not a new one for every new HTML5 type)
• adjust renderer to log a dev warning when secret, submit, file, hidden, checkbox or radio is used (because there are already separate components for them), or perhaps just throw exception?
• Optionally: if type is number or range, and there's a <f:validateXxxRange> then automatically render min and max as well

Other ticket is basically:

• Add about 48 new attributes all starting with on to about 12 existing components, and take into account that we should repeat this every 5~10 years.

[BalusC]

<h:inputText type> has been added: eclipse-ee4j/mojarra@6733916

Before looking at min/max/step attributes I'm awaiting feedback/objections for

Moreover, it would particularly on number/range based inputs be totally awesome if any minimum and maximum attribute of any attached <f:validateXxxRange> is consulted during render so that it's automatically rendered as min and max attributes.

If no feedback nor objections then I won't implement that (but only add the three new attributes).

[BalusC]

I won't add the three new attributes in context of this ticket either. It's going to be a little more involved because people will be expecting server side validation on them and these should technically speaking also be compatible with date types such as type="datetime-local" and type="time". This really needs to be well thought out. I was initially thinking of getMin() and getMax() attributes being of Comparabe<T> type where T should be assignable to whatever is returned by getValue(). But that deserves a separate ticket for discussion.