<f:param> violates the JSF spec

Details

Description

Since nothing seems to be happening with MYFACES-1723, I'm raising this major bug against the JSF 1.2 specification.

Summary: MyFaces 1.2.3 does not support <f:param name="id" /> under Microsoft Internet Explorer, which violates the JSF 1.2 specification;
cf. section 4.1.11 UIParameter and section 9.4.8 <f:param> the 'name' attribute of <f:param> is a String with no specific exceptions for a name of "id".

Some additional details: with myfaces-api-1.2.2.jar and myfaces-impl-1.2.2.jar, using <f:param name="id" /> works;
with myfaces-api-1.2.3.jar and myfaces-impl-1.2.3.jar using <f:param name="id" /> fails, e.g. an

<h:commandLink actionListener="#

{myController.selectId}

">
<f:param name="id" value="123" />
</h:commandLink>

when submitted does not pass the param to selectId(), that is: the value in

Activity

As quoted from Gertjan van Oosten <gertjan@West.NL>:
> To follow-up on my own message: the classes from r645741 seem to work,
> the classes from r647237 fail under MSIE. So the incompatible change
> seems to appear first after:
>
> 2008-04-11 17:39 lu4242
> * [r647237]
> core/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java,
> core/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlLinkRendererBase.java,
> core/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlRendererUtils.java:
> fix MYFACES-1855 hidden fields created when using h:commandLink
> and f:param should be created and removed using javascript
>
>
> [All this is in myfaces/shared/trunk_3.0.x]

Then if I re-enable the lines on trunk commented out in r647237 in
HtmlButtonRendererBase and HtmlLinkRendererBase, it works again.

Gertjan van Oosten
added a comment - 30/Jul/08 12:20 Copied from MyFaces Dev list:
As quoted from Gertjan van Oosten <gertjan@West.NL>:
> To follow-up on my own message: the classes from r645741 seem to work,
> the classes from r647237 fail under MSIE. So the incompatible change
> seems to appear first after:
>
> 2008-04-11 17:39 lu4242
> * [r647237]
> core/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlButtonRendererBase.java,
> core/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlLinkRendererBase.java,
> core/src/main/java/org/apache/myfaces/shared/renderkit/html/HtmlRendererUtils.java:
> fix MYFACES-1855 hidden fields created when using h:commandLink
> and f:param should be created and removed using javascript
>
>
> [All this is in myfaces/shared/trunk_3.0.x]
Then if I re-enable the lines on trunk commented out in r647237 in
HtmlButtonRendererBase and HtmlLinkRendererBase, it works again.
I'll attach a patch

So, only if the value returned is not undefined it is checked again if is an INPUT. If does not exist this property just create but if exists do not create and set the value (since is was defined before using html).

It could be good if I have some feedback about this solution(since this part has been a very problematic part and any change must be done with care), if not I'll commit it.

Leonardo Uribe
added a comment - 30/Jul/08 18:01 After checking the problem and doing some intensive tests, the problem is the behavior of form.elements ['xxx'] method on IE.
In the method oamSetHiddenInput it says:
if(typeof form.elements [name] =='undefined')
{
...................
}
but form.elements ['id'] or form.elements ['name'] returns the attribute value rather than the child (on firefox just return undefined). So, the child is never added to the dom tree.
The solution is check if the value is a "INPUT", doing something like this:
function oamSetHiddenInput(formname, name, value)
{
var form = document.forms [formname] ;
if(!typeof form.elements [name] =='undefined' && form.elements [name] .nodeName=='INPUT')
{
form.elements[name].value=value;
}
else
{
var newInput = document.createElement('input');
newInput.setAttribute('type','hidden');
newInput.setAttribute('id',name);
newInput.setAttribute('name',name);
newInput.setAttribute('value',value);
form.appendChild(newInput);
}
}
So, only if the value returned is not undefined it is checked again if is an INPUT. If does not exist this property just create but if exists do not create and set the value (since is was defined before using html).
It could be good if I have some feedback about this solution(since this part has been a very problematic part and any change must be done with care), if not I'll commit it.

Hi, found that when I test to click the link generated by h:commandLink using Windows Mobile 6 emulator, the link just has no response. And after I applied back the patch mentioned in myfaces-1900-patch.txt, it works again. Please un-comment back the code mentioned in myfaces-1900-patch.txt. It is because the Windows Mobile doesn't support the document.createElement() and form.appendChild() inside the javascript function oamSetHiddenInput

Alan Chan
added a comment - 14/Dec/09 01:51 Hi, found that when I test to click the link generated by h:commandLink using Windows Mobile 6 emulator, the link just has no response. And after I applied back the patch mentioned in myfaces-1900-patch.txt, it works again. Please un-comment back the code mentioned in myfaces-1900-patch.txt. It is because the Windows Mobile doesn't support the document.createElement() and form.appendChild() inside the javascript function oamSetHiddenInput
The emulator I used to test is downloaded from here:
http://www.microsoft.com/downloads/details.aspx?familyid=38C46AA8-1DD7-426F-A913-4F370A65A582&displaylang=en#filelist