TheCoder4eu / BootsFaces-OSP

BootsFaces - Open Source Project
Apache License 2.0
246 stars 102 forks source link

Complex input Id rendering(touchSpin, colorPicker ...) #1047

Closed Lb-lea closed 2 months ago

Lb-lea commented 5 years ago

Hello, I am wondering if there is a particular reason you choose to render the input of the touchSpin and the colorPicker as input_form:ID when date picker is rendered as fom:ID_Input?

It a bit troublesome link the labels with those who are rendered as input_form:ID

Take this form:

<h:form id="form">
<h:outputLabel for="date_start_Input">Start date  </h:outputLabel>
<b:dateTimePicker id="date_start" [...]/>

<h:outputLabel for="input_spinner"   </h:outputLabel>
<b:touchSpin  id="spiner" />
</h:form>

the Label "for" id rendered as "form:date_start_Input" and the input of the date picker as well => that works. However the touchSpin's Id will be input_form:spinner whilst the label is waiting for a "form:Input_spinner". Because the "form:" part is rendered by JSF itself, I don't really know how to link these components with their labels......

Additionally it is also best to always render the ID the same way so that developers don't have to remember which component should be addressed with just the ID (like native JSF component), which should be addressed with the "input" before the ID, witch with the "Input" after the ID....

There are two solution switching colorPicker, touchSpin, inputText, inputTextArea so that they match the way the date-picker's ID is rendered (which seems pretty easy) or having a b:outputlabel that can render the input_ in the for. But the latter solution is pretty ugly since it would only work with BF components ( since JSF doesn't render its component that way).

Ideally that would also be nice if the input had the id is really assigned like the JSF native component so we don't have to think about having to add the "_Input" but it would change a lot of things in the way the components are rendered.

stephanrauh commented 5 years ago

Oops. Your question has a simple answer: the components have been developed by different developers, each of them employing their own individual coding style. In general, that doesn't make any difference, so we didn't notice. Truth to tell, we didn't even seen any need to check such a detail, so we didn't.

However, you've got a point. Let me ponder about this for a moment. I hate introducing incompatibilities by fixing bugs. You never know who relies on this particular bug.

BTW, I wonder if we need a <b:outputLabel /> since a long time, but fixing weird ids shouldn't be the use case to introduce such a widget. :)

stephanrauh commented 2 months ago

I'm afraid development of BootsFaces has slowed down considerably. We'll never manage to address this issue. Let's close it.