incubator-adffaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon_Less...@DMR.CA
Subject Tr : (ADFFACES-44) <af:validateRegExp/> does not allow EL for noMatchMessageDetail
Date Tue, 11 Jul 2006 14:53:15 GMT

I posted a patch for this issue, however it hsould not be closed yet as 
more validators have the same issues. Basically, I did the following to 
fix it:

I added the following to

  protected Object getNoMatchMessageDetailNoEval()
    Object obj = 
    if (obj != null)
      return obj.toString();

    return _facesBean.getValueBinding(_NO_MATCH_MESSAGE_DETAIL_KEY);

and changed the call in _getNoMatchFoundMessage to use the previous 

The same strategy could be applied to most validator. Therefore, I was 
wondering if the getNoMatchMessageDetailNoEval would not benefit from 
being added to FacesBean instead as maybe 
public Object getUnevaluatedProperty or something like that. The method 
would simply return the local value if it exists, or the value binding 
without evaluating if it don't.


Simon Lessard
Fujitsu Consulting

----- Forwarded by Simon Lessard/NOTES on 2006-07-11 10:49 -----

"Simon Lessard (JIRA)" <>
2006-07-11 10:43
Please respond to adffaces-issues
        Subject:        [jira] Updated: (ADFFACES-44) <af:validateRegExp/> 
does not allow EL for noMatchMessageDetail

[ ]

Simon Lessard updated ADFFACES-44:

Status: Patch Available  (was: Open)

> <af:validateRegExp/> does not allow EL for noMatchMessageDetail
> ---------------------------------------------------------------
>          Key: ADFFACES-44
>          URL:
>      Project: MyFaces ADF-Faces
>         Type: Bug

>     Reporter: Simon Lessard

> I copied this bug from OTN at
> You cannot specify a noMatchMessageDetail using EL pointing on a 
resource file when using the <af:validateRegExp/>  tag.
> The reproduction case is:
> [code]
> <f:loadBundle basename="some.resource.file" var="res"/>
> <af:inputText>
>   <af:validateRegExp pattern="\w*" 
> </af:inputText>
> [/code]

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message