I finally had some time to investigate this.

The problem appears to be that in Tomahawk 1.1.9, t:messages renderer
returns the id rather than the clientId of the component.  This is
exactly the opposite of what Michael Heinen found in his original
message.   Unfortunately it means that only the last piece of the
clientId is replaced in the message, rather than the entire client id.


    public static String findInputId(FacesContext facesContext, String
inputClientId)

[...]

        return 
info==null?null:(info.getForComponent()==null?null:info.getForComponent().getId());

Can anyone think of a reason why we would be returning the Id instead
of the clientId?   Can anyone think of a use case where the generated
message would be using the Id instead of the client id?   My limited
testing shows that the client-id is used in the FacesMessages.




On Fri, Apr 2, 2010 at 1:43 PM, Mike Kienenberger <[email protected]> wrote:
> Michael, I'm having the same problem you had before using
>
> myfaces-api-1.2.8.jar
> tomahawk-1.1.9.jar
>
> Were you saying it was caused by a patch you made, or by an incorrect
> patch MyFaces incorrectly applied?
>
> This page code:
> -----------------------------------------------
>                                        <t:messages
>                                         globalOnly="true"
>                                         showDetail="true" />
>
>                                        <t:messages
>                                         globalOnly="false"
>                                         showDetail="true" />
>
>                                                <h:outputLabel 
> for="accountPaymentAmountInput"
>                                                        value="Amount" />
>                                                <h:inputText 
> id="accountPaymentAmountInput"
>                                                        
> binding="#{page.accountPaymentAmountInput}"
>                                                        required="true"
>                                                        
> value="#{page.accountPaymentAmount}">
>                                                </h:inputText>
> -----------------------------------------------
>
> results in
>
> ========================
> masterForm:enterPaymentForm:Amount: Validation Error: Value is required.
> ========================
>
>
> On Tue, Dec 22, 2009 at 12:49 PM, Michael Heinen
> <[email protected]> wrote:
>> I found the issue during the creation of a small test project.
>> It was caused by a not correctly migrated patch for the UIInput.class.
>>
>> Michael
>>
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]] On Behalf 
>> Of Jakob Korherr
>> Sent: Dienstag, 22. Dezember 2009 17:05
>> To: MyFaces Discussion
>> Subject: Re: [tomahawk] replaceIdWithLabel not working in t:messages after 
>> update to JSF 1.2
>>
>> Hi Michael,
>>
>> I'm sorry, but I can not reproduce your problem. On my machine it is "User:
>> Validierungsfehler: Eingabe erforderlich.".
>>
>> Can you please provide more information about your jsp.
>>
>> Regards,
>> Jakob
>>
>>
>> 2009/12/22 Michael Heinen <[email protected]>
>>
>>> Hi,
>>>
>>> I have another migration issue:
>>> Error messages are rendered with the component ids instead of the label
>>> after update from myfaces 1.1.6 to 1.2.8 and tomahawk to 12_1.1.9
>>>
>>> jsp:
>>> <h:outputLabel for="name" value="User"/>
>>> <h:panelGroup>
>>>  <h:inputText id="name" value="#{MyController.name}" required="true">
>>>
>>> Class
>>> org.apache.myfaces.renderkit.html.ext.HtmlMessagesRenderer.getSummary(...)
>>> contains following line (86):
>>>
>>> msgSummary =
>>> msgSummary.replaceAll(HtmlMessageRenderer.findInputId(facesContext,
>>> msgClientId),inputLabel);
>>>
>>> Content:
>>> msgSummary= name: Validierungsfehler: Eingabe erforderlich.
>>> HtmlMessageRenderer.findInputId(facesContext, msgClientId) returns
>>> loginForm:name
>>> inptutLabel= User
>>>
>>> So the problem is that findInputId returns the full qualified clientid
>>> instead of the id.
>>> This worked with the old 1.1 jars.
>>>
>>> Any ideas?
>>> Michael
>>>
>>
>

Reply via email to