struts-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SHALE-185) @Value is too restrictive on naming
Date Thu, 08 Jun 2006 22:02:16 GMT
    [ http://issues.apache.org/struts/browse/SHALE-185?page=comments#action_37456 ] 

Craig McClanahan commented on SHALE-185:
----------------------------------------

I agree with your summary statement.  At the moment, I'm leaning towards your solution #1,
but the idea of annotating a getter or setter (like you can do in JPA entity classes) might
also be a good idea.


> @Value is too restrictive on naming
> -----------------------------------
>
>          Key: SHALE-185
>          URL: http://issues.apache.org/struts/browse/SHALE-185
>      Project: Shale
>         Type: Bug

>   Components: Tiger
>     Versions: 1.0.3
>  Environment: Windows XP sp3, Weblogic 9.1, MyFaces 1.1.3
>     Reporter: Adam Brod

>
> We use a prefix convention for our member variables.  All private member fields being
with 'm_'.  For example, in my managed bean, I have a private field m_fileId with getFileId()
and setFileId() methods.
> This works fine when I use the faces-config.xml to configure my beans, because I just
say the property-name is "fileId".  This doesn't work for Shale-Tiger - I get an exception
because there is no setter for m_fileId.  As far as I know, the Java Beans spec doesn't mandate
the name of the private variable, just the getters and setters.
> Shale-Tiger should be more flexible to support this.  
> Here are three possible solutions:
> 1)  The @Value annotation should take an optional property field to allow me to specify
the property the field corresponds to.  E.g.
> @Value(value="#{param.fileId}", property="fileId")
> private Long m_fileId;
> 2) The @Value annotation could be applied to methods or fields (much like JPA annotations).
 E.g.:
> @Value("#{param.fileId}")
> public void setFileId(Long fileId) { this.m_fileId = fileId; }
> 3) I specify some mapping rules somewhere that define all member fields begin with "m_",
so the annotation processor should handle that.  That is similar to what Eclipse does.  You
can configure field prefixes, and then the tool automatically handles those when generating
getters and setters.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message