hello i try of make the same of you, if you can show me your code,
i try with this but don't run
*<tr:selectManyCheckbox value="#{reoffermanager.dealTypeSelected}"
converter="dealTypeConverter"
binding="#{reoffermanager.tableDealType}"
id="listDealType" >
<t:dataList value="#{constantManager.dealTypeList}"
var="item" rowIndexVar="row" forceIdIndex="true">
<tr:selectItem value="#{item}" />
</t:dataList>*
2008/11/26 Leonardo Uribe <[EMAIL PROTECTED]>
>
>
> On Wed, Nov 26, 2008 at 9:14 AM, <[EMAIL PROTECTED]>wrote:
>
>> Hello,
>>
>>
>>
>> Today we noticed that the t:checkbox component used inside a
>> t:selectManyCheckbox generates checkboxes all with the same ID. This is a
>> probably since we use h:outputLabel with the "for" attribute, mainly for
>> accessibility purposes, but the ids don't match. We have something like this
>> in the page.
>>
>>
>>
>> <t:selectManyCheckbox
>>
>> id=*"articlesChecked"*
>>
>> value="#{mbArticles.articlesChecked}"
>>
>> layout=*"spread"*
>>
>> onclick=*"checkState(this,false,'articlesList')"*>
>>
>>
>>
>>
>>
>> Then a bit further down we have this in a dataList
>>
>>
>>
>>
>>
>> <h:outputLabel for=*"articleCheckbox"*>
>>
>> <t:checkbox index="#{count}" for=*":articlesForm:articlesChecked"*
>> id=*"articleCheckbox"*/>
>>
>>
>>
>> So the checkboxes generated are like
>>
>>
>>
>> <input type="checkbox" name="articlesChecked" id="articlesChecked" />
>>
>>
>>
>> I know the HTML spec pretty well and for this case only the "name"
>> attribute really needs to be repeated, the id can be unique and should be,
>> it's actually invalid to have duplicate ids in the DOM (then again so is an
>> id starting with the "_" character. I'll never understand that decision).
>>
>>
>>
>> I extended the HtmlCheckboxRenderer and basically changed it such that it
>> will output the name attribute as the clientId of the UISelectMany component
>> and the ID as the clientId of the HtmlCheckBox component. I override
>> encodeEnd and kept it identical except I have my own renderSingleCheckBox
>> method, which is also identical except it calls my version of
>> renderCheckBox, which is nearly identical except for this part:
>>
>>
>>
>>
>>
>> *if* (renderId) {
>>
>> *if* (StringUtils.*isNotEmpty*(checkboxClientId)) {
>>
>> writer.writeAttribute(HTML.*ID_ATTR*, checkboxClientId, *
>> null*);
>>
>> }
>>
>> }
>>
>>
>>
>> checkboxClientId is an extra parameter passed in.
>>
>>
>>
>> So far this solution seems to work. The ids are correctly generated and
>> the functionality hasn't broken (meaning I can select a few checkboxes and
>> they're picked up on the other side).
>>
>>
>>
>> So my questions here are:
>>
>>
>>
>> Is there any possible side affect that I haven't though about? I probably
>> haven't tested every possible scenario of use here.
>>
>>
>>
>> Has this been addressed already in a later version of tomahawk? I'm using
>> 1.1.6 here. If not then it should be updated in a future release of
>> Tomahawk.
>>
>>
>>
> Hi
>
> Yes, see https://issues.apache.org/jira/browse/TOMAHAWK-1188 for details.
> I hope this helps.
>
> regards
>
> Leonardo Uribe
>
>
>> Matt
>>
>>
>>
>>
>>
>
>
