Sorry, meaning that I am just verifying your patch. Will be applying it for you

On 10/17/07, Andrew Robinson <[EMAIL PROTECTED]> wrote:
> I realize that, I'm trying to fix it though :)
>
> On 10/17/07, Bernhard Huemer <[EMAIL PROTECTED]> wrote:
> > Hello,
> >
> > that's what I've already detected.
> >
> > "That seems to be a trivial bug of the Maven Faces Plugin's
> > MyFacesComponentGenerator. In order to the generate the "fancy getter",
> > it uses the name of the given parameter rather than the name of the
> > property."
> >
> > regards,
> > Bernhard
> >
> > On 10/17/2007 +0200,
> > "Andrew Robinson" <[EMAIL PROTECTED]> wrote:
> > > I'm looking into this as a problem with the maven-faces-plugin source.
> > > What is interesting is the trunk is pointing at an old version of the
> > > plugin (1.2.1.1).
> > >
> > > I'll try to see what is going on with the plugin and see if I can use
> > > 1.2.4-SNAPSHOT to debug the issue. It seems like the
> > > MyFacesComponentGenerator is not using the correct variable to produce
> > > the getter method body
> > >
> > > -Andrew
> > >
> > > On 10/17/07, Mike Kienenberger (JIRA) <[email protected]> wrote:
> > >>     [ 
> > >> https://issues.apache.org/jira/browse/MYFACES-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535594
> > >>  ]
> > >>
> > >> Mike Kienenberger commented on MYFACES-1745:
> > >> --------------------------------------------
> > >>
> > >> At this point, you probably would be better off asking on the dev list 
> > >> on how to configure the generation process.
> > >>
> > >> I was only half-joking about the permissions, but it could be done on 
> > >> most operating systems.   For Windows, which is what it sounds like 
> > >> you're using, you can hit properties for a file (or folder), then the 
> > >> security tab, then click "Advanced" and most likely the access control 
> > >> will be "Allow Everyone Full Control"
> > >>
> > >> You can edit that access control to disallow "delete".   Just remember 
> > >> to change it back after you are done :-)
> > >>
> > >>
> > >>> for-Attribute of UIMessage and HtmlOutputLabel does not work with an EL 
> > >>> Expression
> > >>> ----------------------------------------------------------------------------------
> > >>>
> > >>>                 Key: MYFACES-1745
> > >>>                 URL: https://issues.apache.org/jira/browse/MYFACES-1745
> > >>>             Project: MyFaces Core
> > >>>          Issue Type: Bug
> > >>>    Affects Versions: 1.2.1-SNAPSHOT
> > >>>         Environment: Tomcat 6.0.15 (snapshot), Facelets 1.1.14
> > >>>            Reporter: Jan Ziegler
> > >>>         Attachments: MyFaces-1745.patch
> > >>>
> > >>>
> > >>> When using an EL-Expression in the 'for'-Attribute of a UIMessage or 
> > >>> HtmlOutputPanel, the EL is always resolved to null.
> > >>>
> > >>> Here is an Example:
> > >>> ...
> > >>> <h:form>
> > >>>       <h:outputLabel for="#{testBean.test}" />
> > >>>       <h:inputText id="#{testBean.test}" value="" required="true" />
> > >>>       <h:message for="#{testBean.test}" />
> > >>>       <h:commandButton value="click" />
> > >>> </h:form>
> > >>> ...
> > >>> You see that the 'for'-Attributes of the message and label as well as 
> > >>> the 'id'-Attribute of the inputText refer to the same value which 
> > >>> returns some valid string in my TestBean:
> > >>> ...
> > >>> public String getTest()
> > >>> {
> > >>>     return "testID";
> > >>> }
> > >>> ...
> > >>> When rendering the page, a message will never be rendered (even no 
> > >>> value is given but the field is required) and the label cannot be 
> > >>> linked to the input field - there appears two error messages on the 
> > >>> console:
> > >>> Attribute 'for' of label component with id j_id1:j_id2 is not defined
> > >>> Attribute 'for' of UIMessage must not be null
> > >>> which means the value of the EL-Expression resolves to null I think. In 
> > >>> other cases, it is no problem to resolve the value, e.g. in an 
> > >>> HtmlOutputText:
> > >>> <h:outputText value="#{testBean.test}" />
> > >>> Therefor I looked into the source code of UIMessage and 
> > >>> HtmlOutputLabel. I think I found the bug. Look at the 
> > >>> 'getFor()'-function of UIMessage (also in HtmlOutputLabel):
> > >>>   public String getFor()
> > >>>   {
> > >>>     if (_for != null)
> > >>>     {
> > >>>       return _for;
> > >>>     }
> > >>>     ValueExpression expression = getValueExpression("forParam");
> > >>>     if (expression != null)
> > >>>     {
> > >>>       return 
> > >>> (String)expression.getValue(getFacesContext().getELContext());
> > >>>     }
> > >>>     return null;
> > >>>   }
> > >>> I think 'forParam' is the wrong identifier for the ValueExpression 
> > >>> ´cause in the Tag-classes, a value expression of the 'for'-Attribute is 
> > >>> set via
> > >>> comp.setValueExpression("for", _for);
> > >>> A fix should be to use 'forParam' as an identifier in the Tag classes 
> > >>> or 'for' as an identifier in the component-classes to use the same 
> > >>> identifier for the value expression in all participants
> > >>> Am I right with that?
> > >> --
> > >> This message is automatically generated by JIRA.
> > >> -
> > >> You can reply to this email to add a comment to the issue online.
> > >>
> > >>
> > >
> >
> >
>

Reply via email to