[jira] [Commented] (MYFACES-3259) Custom Validator tag attributes are not configured when used with default tag handler in wrapping mode
[ https://issues.apache.org/jira/browse/MYFACES-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13086164#comment-13086164 ] Leonardo Uribe commented on MYFACES-3259: - This is what I have so far. The solution works but looking more carefully this change should follow the same rules as f:ajax. For example, f:ajax does not pass through composite components, but pass over anything else. The strange thing here is f:validateBean does not have that obvious restriction (but maybe that restriction does not apply after all). I still don't know what to do in this case. What we need here is have some examples about what should work and what shouldn't work, and then implement something according to that. Custom Validator tag attributes are not configured when used with default tag handler in wrapping mode -- Key: MYFACES-3259 URL: https://issues.apache.org/jira/browse/MYFACES-3259 Project: MyFaces Core Issue Type: Bug Reporter: Matt Benson Attachments: MYFACES-3259-1.patch, MYFACES-3259.tar.gz, MYFACES-3259.tar.gz demo forthcoming; it would seem the FaceletCompositionContext would need to keep track of the delegate as well as the id of enclosing validators in order to be able to apply the xml attributes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TOBAGO-1019) Automatic position of popup is not computed correctly
Automatic position of popup is not computed correctly - Key: TOBAGO-1019 URL: https://issues.apache.org/jira/browse/TOBAGO-1019 Project: MyFaces Tobago Issue Type: Bug Components: Themes Affects Versions: 1.5.0-beta-1 Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [COMMUNITY] MyFaces += Matt Benson
Welcome to the club Matt! Cheers, Jan-Kees 2011/8/16 Grant Smith work.gr...@gmail.com Welcome ! On Tue, Aug 16, 2011 at 12:26 PM, Matt Benson gudnabr...@gmail.comwrote: Thanks all! Matt On Tue, Aug 16, 2011 at 2:18 PM, Leonardo Uribe lu4...@gmail.com wrote: Welcome! Leonardo 2011/8/16 Jakob Korherr jakob.korh...@gmail.com: Welcome, Matt! Regards, Jakob 2011/8/16 Gerhard Petracek gpetra...@apache.org: The MyFaces PMC is proud to announce a new addition to our community. Please welcome Matt Benson as the newest MyFaces committer! Matt is an active member of the MyFaces community, especially in MyFaces Core and MyFaces Extensions Validator. @Matt: Please add yourself to the Master-POM at https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml Welcome regards, Gerhard -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Grant Smith - V.P. Information Technology Marathon Computer Systems, LLC.
[jira] [Resolved] (TOBAGO-1019) Automatic position of popup is not computed correctly
[ https://issues.apache.org/jira/browse/TOBAGO-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Schnurpfeil resolved TOBAGO-1019. - Resolution: Fixed Fix Version/s: 1.5.0-beta-2 Automatic position of popup is not computed correctly - Key: TOBAGO-1019 URL: https://issues.apache.org/jira/browse/TOBAGO-1019 Project: MyFaces Tobago Issue Type: Bug Components: Themes Affects Versions: 1.5.0-beta-1 Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil Fix For: 1.5.0-beta-2 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [COMMUNITY] MyFaces += Matt Benson
Welcome On Wed, Aug 17, 2011 at 8:52 AM, Jan-Kees van Andel jankeesvanan...@gmail.com wrote: Welcome to the club Matt! Cheers, Jan-Kees 2011/8/16 Grant Smith work.gr...@gmail.com Welcome ! On Tue, Aug 16, 2011 at 12:26 PM, Matt Benson gudnabr...@gmail.com wrote: Thanks all! Matt On Tue, Aug 16, 2011 at 2:18 PM, Leonardo Uribe lu4...@gmail.com wrote: Welcome! Leonardo 2011/8/16 Jakob Korherr jakob.korh...@gmail.com: Welcome, Matt! Regards, Jakob 2011/8/16 Gerhard Petracek gpetra...@apache.org: The MyFaces PMC is proud to announce a new addition to our community. Please welcome Matt Benson as the newest MyFaces committer! Matt is an active member of the MyFaces community, especially in MyFaces Core and MyFaces Extensions Validator. @Matt: Please add yourself to the Master-POM at https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml Welcome regards, Gerhard -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Grant Smith - V.P. Information Technology Marathon Computer Systems, LLC. -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [COMMUNITY] MyFaces += Matt Benson
Welcome Matt Regards Rudy On 17 August 2011 09:02, Matthias Wessendorf mat...@apache.org wrote: Welcome On Wed, Aug 17, 2011 at 8:52 AM, Jan-Kees van Andel jankeesvanan...@gmail.com wrote: Welcome to the club Matt! Cheers, Jan-Kees 2011/8/16 Grant Smith work.gr...@gmail.com Welcome ! On Tue, Aug 16, 2011 at 12:26 PM, Matt Benson gudnabr...@gmail.com wrote: Thanks all! Matt On Tue, Aug 16, 2011 at 2:18 PM, Leonardo Uribe lu4...@gmail.com wrote: Welcome! Leonardo 2011/8/16 Jakob Korherr jakob.korh...@gmail.com: Welcome, Matt! Regards, Jakob 2011/8/16 Gerhard Petracek gpetra...@apache.org: The MyFaces PMC is proud to announce a new addition to our community. Please welcome Matt Benson as the newest MyFaces committer! Matt is an active member of the MyFaces community, especially in MyFaces Core and MyFaces Extensions Validator. @Matt: Please add yourself to the Master-POM at https://svn.apache.org/repos/asf/myfaces/myfaces-master-pom/trunk/pom.xml Welcome regards, Gerhard -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Grant Smith - V.P. Information Technology Marathon Computer Systems, LLC. -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Rudy De Busscher http://www.c4j.be
Re: [VOTE] release of myfaces test 1.0.4
Hi Leo, Actually I would really like to see MYFACESTEST-56 (JSF 2.1 mock support) fixed, before the next release, but I don't want to block the release(s) of MyFaces core.. Thus my vote is +0. Regards, Jakob 2011/8/17 Leonardo Uribe lu4...@gmail.com: +1 2011/8/17 Leonardo Uribe lu4...@gmail.com: Hi, I was running the needed tasks to get the 1.0.4 release of Apache MyFaces Test out. Note these artifacts are necessary to start the release of myfaces core 2.0.8 and 2.1.2. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.test v1.0.4 [1] The artifacts are deployed to nexus repository [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Please take a look at the 1.0.4 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-046/org/apache/myfaces/test/ https://repository.apache.org/content/groups/staging/org/apache/myfaces/test/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfacestest104binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310951version=12317607 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: Spec issue for handling of custom validator tag attributes in wrapping mode
Hi Matt, Will do ;) Regards, Jakob 2011/8/16 Matt Benson gudnabr...@gmail.com: (@Jakob) Can we escalate to the EG? http://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-1033 Thanks, Matt -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [VOTE] release of myfaces test 1.0.4
Hi Jakob Yes, I know but unfortunately we don't have much time. Fortunately JSF 2.1 has few changes from API part so in practice you can use 2.0 without problem. For now we need this artifact because it contains some bug fixes necessary to run some myfaces core test. regards, Leonardo Uribe 2011/8/17 Jakob Korherr jakob.korh...@gmail.com: Hi Leo, Actually I would really like to see MYFACESTEST-56 (JSF 2.1 mock support) fixed, before the next release, but I don't want to block the release(s) of MyFaces core.. Thus my vote is +0. Regards, Jakob 2011/8/17 Leonardo Uribe lu4...@gmail.com: +1 2011/8/17 Leonardo Uribe lu4...@gmail.com: Hi, I was running the needed tasks to get the 1.0.4 release of Apache MyFaces Test out. Note these artifacts are necessary to start the release of myfaces core 2.0.8 and 2.1.2. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.test v1.0.4 [1] The artifacts are deployed to nexus repository [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Please take a look at the 1.0.4 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-046/org/apache/myfaces/test/ https://repository.apache.org/content/groups/staging/org/apache/myfaces/test/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfacestest104binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310951version=12317607 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: [VOTE] release of myfaces test 1.0.4
+1 to release On Wed, Aug 17, 2011 at 8:02 AM, Leonardo Uribe lu4...@gmail.com wrote: Hi Jakob Yes, I know but unfortunately we don't have much time. Fortunately JSF 2.1 has few changes from API part so in practice you can use 2.0 without problem. For now we need this artifact because it contains some bug fixes necessary to run some myfaces core test. regards, Leonardo Uribe 2011/8/17 Jakob Korherr jakob.korh...@gmail.com: Hi Leo, Actually I would really like to see MYFACESTEST-56 (JSF 2.1 mock support) fixed, before the next release, but I don't want to block the release(s) of MyFaces core.. Thus my vote is +0. Regards, Jakob 2011/8/17 Leonardo Uribe lu4...@gmail.com: +1 2011/8/17 Leonardo Uribe lu4...@gmail.com: Hi, I was running the needed tasks to get the 1.0.4 release of Apache MyFaces Test out. Note these artifacts are necessary to start the release of myfaces core 2.0.8 and 2.1.2. Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.test v1.0.4 [1] The artifacts are deployed to nexus repository [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [4]. Please take a look at the 1.0.4 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-046/org/apache/myfaces/test/ https://repository.apache.org/content/groups/staging/org/apache/myfaces/test/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfacestest104binsrc [4] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310951version=12317607 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at -- Grant Smith - V.P. Information Technology Marathon Computer Systems, LLC.
[jira] [Created] (MYFACES-3282) Update myfaces-builder-plugin unpack goal to maven 3
Update myfaces-builder-plugin unpack goal to maven 3 Key: MYFACES-3282 URL: https://issues.apache.org/jira/browse/MYFACES-3282 Project: MyFaces Core Issue Type: Bug Components: build process Reporter: Leonardo Uribe Assignee: Leonardo Uribe Unpack goal needs to be updated to use maven-dependency-plugin 2.3, to make it work well when site is generated on maven 3 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MYFACES-3282) Update myfaces-builder-plugin unpack goal to maven 3
[ https://issues.apache.org/jira/browse/MYFACES-3282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3282. - Resolution: Fixed Update myfaces-builder-plugin unpack goal to maven 3 Key: MYFACES-3282 URL: https://issues.apache.org/jira/browse/MYFACES-3282 Project: MyFaces Core Issue Type: Bug Components: build process Reporter: Leonardo Uribe Assignee: Leonardo Uribe Unpack goal needs to be updated to use maven-dependency-plugin 2.3, to make it work well when site is generated on maven 3 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (EXTCDI-215) support for the generic support module of extval
support for the generic support module of extval Key: EXTCDI-215 URL: https://issues.apache.org/jira/browse/EXTCDI-215 Project: MyFaces CODI Issue Type: Improvement Components: JEE-JSF12-Module, JEE-JSF20-Module Affects Versions: 1.0.0 Reporter: Gerhard Petracek Assignee: Gerhard Petracek -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (EXTCDI-215) support for the generic support module of extval
[ https://issues.apache.org/jira/browse/EXTCDI-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gerhard Petracek resolved EXTCDI-215. - Resolution: Fixed Fix Version/s: 1.0.1 support for the generic support module of extval Key: EXTCDI-215 URL: https://issues.apache.org/jira/browse/EXTCDI-215 Project: MyFaces CODI Issue Type: Improvement Components: JEE-JSF12-Module, JEE-JSF20-Module Affects Versions: 1.0.0 Reporter: Gerhard Petracek Assignee: Gerhard Petracek Fix For: 1.0.1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TRINIDAD-2130) Skinning: support separate style sheets for secure + non-secure pages
Skinning: support separate style sheets for secure + non-secure pages - Key: TRINIDAD-2130 URL: https://issues.apache.org/jira/browse/TRINIDAD-2130 Project: MyFaces Trinidad Issue Type: Improvement Components: Skinning Reporter: Andy Schwartz Priority: Minor I have an ExternalContext wrapper that modifies urls that are passed to ExternalContext.encodeResourceURL(). This includes urls for images referenced by Trinidad skin definitions. One possible modification involves converting relative URLs to absolute URLs (eg. prepending a CDN prefix), including the protocol/host/port. A problem with this is that we share a single generated style sheet across http and https pages. This means that if I generate absolute uris with the http: protocol, these uris will be written into a generated .css file that would be shared by secure/https pages, in which case the browser may warn about mixed secure/non-secure content. I would like to avoid this issue by enhancing Trinidad skinning to support generation of separate style sheets for secure and non-secure pages. That way, my ExternalContext wrapper could produce absolute uris with the appropriate protocol for the current request and avoid mixing secure/non-secure content. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: snapshot download link
hi leo, for sure we can discuss it. the question is if there are that many users who (are allowed to) use snapshot versions and who rely on the autom. deployed snapshots for their daily work. regards, gerhard 2011/8/17 Leonardo Uribe lu4...@gmail.com Hi Gerhard Ok, I was thinking about create the assembly package just like when myfaces is released, with the javadoc, sources, tlddocs and all necessary libraries. Note the difference between what we have right now, which is just some snapshots on a maven repo. regards, Leonardo Uribe 2011/8/17 Gerhard Petracek gerhard.petra...@gmail.com: hi, @kito: thx for the info. however, this location is deprecated since a quite long time. @leo: actually there are build-jobs for nightly builds (including the deployment of snapshots). however, maybe some sub-projects don't have such build-jobs. regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2011/8/17 Leonardo Uribe lu4...@gmail.com Hi Kito Yes, for snapshots the link as you already know is: https://repository.apache.org/content/repositories/snapshots/org/apache/myfaces/ but there is not any task to create nightly builds on hudson (https://builds.apache.org/view/M-R/view/MyFaces/) right now. I'll keep it in mind. regards, Leonardo Uribe 2011/8/17 Kito Mann kito.m...@virtua.com: Hey guys, FYI, the nightly download link ( http://people.apache.org/builds/myfaces/nightly/) doesn't have any builds. I was able to get a snapshot from the Maven repository, but I thought you should know. --- Kito D. Mann | twitter: kito99 | Author, JSF in Action Virtua, Inc. | http://www.virtua.com | JSF/Java EE training and consulting http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info | twitter: jsfcentral +1 203-404-4848 x3 * Listen to the latest headlines in the JSF and Java EE newscast: http://blogs.jsfcentral.com/roller/editorsdesk/category/JSF+and+Java+EE+Newscast * Keep up with the aftermath of the Oracle/Sun merger: http://www.mergerspeak.com
[jira] [Created] (TRINIDAD-2131) Make it easier to debug viewExpiredExceptions
Make it easier to debug viewExpiredExceptions - Key: TRINIDAD-2131 URL: https://issues.apache.org/jira/browse/TRINIDAD-2131 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 2.0.0 Reporter: Gabrielle Crawford Assignee: Gabrielle Crawford Priority: Trivial ViewExpiredExceptions are fairly common, and the token cache is used for page state tokens, but the tokens aren't really human readable. In order to make it easier to understand what is in the cache we've added a system property for debugging purposes. When enabled we store a map of token - viewId on the session which we use to log something more human readable. In order to use this the tester would set the system property to: -Dorg.apache.myfaces.trinidadinternal.DEBUG_TOKEN_CACHE=true -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3283) #{cc.attr} attributes fail when a child component is accessed outside of the composite component (i.e. in action listeners or other events)
#{cc.attr} attributes fail when a child component is accessed outside of the
composite component (i.e. in action listeners or other events)
---
Key: MYFACES-3283
URL: https://issues.apache.org/jira/browse/MYFACES-3283
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.0.7
Environment: Mac OS 10.6, Tomcat 7
Reporter: Kito D. Mann
If you reference a property of child component anywhere outside of the
composite's context (i.e. in an action method, a component system event
listener, etc.), the property will not be evaluated properly if the expression
is a composite component attribute (i.e. #{cc.attrs.property}). This is
because the EL evaluation code can't find the parent composite component.
For example, consider the composite component:
?xml version=1.0?
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:composite=http://java.sun.com/jsf/composite;
composite:interface
composite:attribute name=label /
composite:attribute name=value required=true /
/composite:interface
composite:implementation
h:outputLabel for=input value=#{cc.attrs.label} /
h:inputText id=input value=#{cc.attrs.value} /
/composite:implementation
/html
The calling page:
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:ui=http://java.sun.com/jsf/facelets;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:ez=http://java.sun.com/jsf/composite/demo;
h:head/h:head
h:body
h:form id=form
h:messages /
ez:input id=composite label=Enter something:
value=#{testBean.value} /
h:commandButton value=Submit
action=#{testBean.testCcAttribute} /
/h:form
/h:body
/html
Here's testBean.testCcAttribute():
public String testCcAttribute() {
HtmlInputText input =
(HtmlInputText)FacesContext.getCurrentInstance().getViewRoot().findComponent(form:composite:input);
UIComponent composite =
FacesContext.getCurrentInstance().getViewRoot().findComponent(form:composite);
String message = Input control label attribute is: +
input.getLabel() + ; Composite label attribute is: +
composite.getAttributes().get(label);
display(message);
return null;
}
This action method generates the following message:
Input control label attribute is: null; Composite label attribute is: Enter
something:
---
Full example WAR attached.
Note this is the same as the following issue with Mojarra:
http://java.net/jira/browse/JAVASERVERFACES-2009.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MYFACES-3283) #{cc.attr} attributes fail when a child component is accessed outside of the composite component (i.e. in action listeners or other events)
[
https://issues.apache.org/jira/browse/MYFACES-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Benson resolved MYFACES-3283.
--
Resolution: Invalid
In cases where you rely on the component stack in this manner you can query
this information in the context of a tree visit (I personally have gotten into
the habit of doing nearly everything in a tree visit for this reason).
#{cc.attr} attributes fail when a child component is accessed outside of the
composite component (i.e. in action listeners or other events)
---
Key: MYFACES-3283
URL: https://issues.apache.org/jira/browse/MYFACES-3283
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.0.7
Environment: Mac OS 10.6, Tomcat 7
Reporter: Kito D. Mann
Attachments: myfaces_cc_issue.war
If you reference a property of child component anywhere outside of the
composite's context (i.e. in an action method, a component system event
listener, etc.), the property will not be evaluated properly if the
expression is a composite component attribute (i.e. #{cc.attrs.property}).
This is because the EL evaluation code can't find the parent composite
component.
For example, consider the composite component:
?xml version=1.0?
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:composite=http://java.sun.com/jsf/composite;
composite:interface
composite:attribute name=label /
composite:attribute name=value required=true /
/composite:interface
composite:implementation
h:outputLabel for=input value=#{cc.attrs.label} /
h:inputText id=input value=#{cc.attrs.value} /
/composite:implementation
/html
The calling page:
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:ui=http://java.sun.com/jsf/facelets;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:ez=http://java.sun.com/jsf/composite/demo;
h:head/h:head
h:body
h:form id=form
h:messages /
ez:input id=composite label=Enter something:
value=#{testBean.value} /
h:commandButton value=Submit
action=#{testBean.testCcAttribute} /
/h:form
/h:body
/html
Here's testBean.testCcAttribute():
public String testCcAttribute() {
HtmlInputText input =
(HtmlInputText)FacesContext.getCurrentInstance().getViewRoot().findComponent(form:composite:input);
UIComponent composite =
FacesContext.getCurrentInstance().getViewRoot().findComponent(form:composite);
String message = Input control label attribute is: +
input.getLabel() + ; Composite label attribute is: +
composite.getAttributes().get(label);
display(message);
return null;
}
This action method generates the following message:
Input control label attribute is: null; Composite label attribute is: Enter
something:
---
Full example WAR attached.
Note this is the same as the following issue with Mojarra:
http://java.net/jira/browse/JAVASERVERFACES-2009.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3283) #{cc.attr} attributes fail when a child component is accessed outside of the composite component (i.e. in action listeners or other events)
[
https://issues.apache.org/jira/browse/MYFACES-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13086672#comment-13086672
]
Kito D. Mann commented on MYFACES-3283:
---
There are lots of things one *can* do. However, this is typical application
developer behavior, and you should be able to reference any component from an
action listener (or, during a PostValidate component event listener, which is
where this problem was discovered) and expect its properties to resolve
normally.
You need to prove that this is valid behavior with respect to the spec in order
to mark it as invalid. Note that the Mojarra folks have not marked it as
invalid.
#{cc.attr} attributes fail when a child component is accessed outside of the
composite component (i.e. in action listeners or other events)
---
Key: MYFACES-3283
URL: https://issues.apache.org/jira/browse/MYFACES-3283
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.0.7
Environment: Mac OS 10.6, Tomcat 7
Reporter: Kito D. Mann
Attachments: myfaces_cc_issue.war
If you reference a property of child component anywhere outside of the
composite's context (i.e. in an action method, a component system event
listener, etc.), the property will not be evaluated properly if the
expression is a composite component attribute (i.e. #{cc.attrs.property}).
This is because the EL evaluation code can't find the parent composite
component.
For example, consider the composite component:
?xml version=1.0?
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:composite=http://java.sun.com/jsf/composite;
composite:interface
composite:attribute name=label /
composite:attribute name=value required=true /
/composite:interface
composite:implementation
h:outputLabel for=input value=#{cc.attrs.label} /
h:inputText id=input value=#{cc.attrs.value} /
/composite:implementation
/html
The calling page:
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:ui=http://java.sun.com/jsf/facelets;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:ez=http://java.sun.com/jsf/composite/demo;
h:head/h:head
h:body
h:form id=form
h:messages /
ez:input id=composite label=Enter something:
value=#{testBean.value} /
h:commandButton value=Submit
action=#{testBean.testCcAttribute} /
/h:form
/h:body
/html
Here's testBean.testCcAttribute():
public String testCcAttribute() {
HtmlInputText input =
(HtmlInputText)FacesContext.getCurrentInstance().getViewRoot().findComponent(form:composite:input);
UIComponent composite =
FacesContext.getCurrentInstance().getViewRoot().findComponent(form:composite);
String message = Input control label attribute is: +
input.getLabel() + ; Composite label attribute is: +
composite.getAttributes().get(label);
display(message);
return null;
}
This action method generates the following message:
Input control label attribute is: null; Composite label attribute is: Enter
something:
---
Full example WAR attached.
Note this is the same as the following issue with Mojarra:
http://java.net/jira/browse/JAVASERVERFACES-2009.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3283) #{cc.attr} attributes fail when a child component is accessed outside of the composite component (i.e. in action listeners or other events)
[
https://issues.apache.org/jira/browse/MYFACES-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13086674#comment-13086674
]
Matt Benson commented on MYFACES-3283:
--
wrt the Mojarra-reported issue, to judge from its description I gauge it may be
slightly more complex and thus could be valid; however the simple case you
outline above does not, as best I can tell, qualify as a situation in which you
should expect the component stack to be in such a state as to resolve properly.
#{cc.attr} attributes fail when a child component is accessed outside of the
composite component (i.e. in action listeners or other events)
---
Key: MYFACES-3283
URL: https://issues.apache.org/jira/browse/MYFACES-3283
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.0.7
Environment: Mac OS 10.6, Tomcat 7
Reporter: Kito D. Mann
Attachments: myfaces_cc_issue.war
If you reference a property of child component anywhere outside of the
composite's context (i.e. in an action method, a component system event
listener, etc.), the property will not be evaluated properly if the
expression is a composite component attribute (i.e. #{cc.attrs.property}).
This is because the EL evaluation code can't find the parent composite
component.
For example, consider the composite component:
?xml version=1.0?
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:composite=http://java.sun.com/jsf/composite;
composite:interface
composite:attribute name=label /
composite:attribute name=value required=true /
/composite:interface
composite:implementation
h:outputLabel for=input value=#{cc.attrs.label} /
h:inputText id=input value=#{cc.attrs.value} /
/composite:implementation
/html
The calling page:
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:ui=http://java.sun.com/jsf/facelets;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:ez=http://java.sun.com/jsf/composite/demo;
h:head/h:head
h:body
h:form id=form
h:messages /
ez:input id=composite label=Enter something:
value=#{testBean.value} /
h:commandButton value=Submit
action=#{testBean.testCcAttribute} /
/h:form
/h:body
/html
Here's testBean.testCcAttribute():
public String testCcAttribute() {
HtmlInputText input =
(HtmlInputText)FacesContext.getCurrentInstance().getViewRoot().findComponent(form:composite:input);
UIComponent composite =
FacesContext.getCurrentInstance().getViewRoot().findComponent(form:composite);
String message = Input control label attribute is: +
input.getLabel() + ; Composite label attribute is: +
composite.getAttributes().get(label);
display(message);
return null;
}
This action method generates the following message:
Input control label attribute is: null; Composite label attribute is: Enter
something:
---
Full example WAR attached.
Note this is the same as the following issue with Mojarra:
http://java.net/jira/browse/JAVASERVERFACES-2009.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (MYFACES-3283) #{cc.attr} attributes fail when a child component is accessed outside of the composite component (i.e. in action listeners or other events)
[
https://issues.apache.org/jira/browse/MYFACES-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Benson reopened MYFACES-3283:
--
RE burden of proof, fair enough. Let's scour the spec and seek clarification
if necessary.
#{cc.attr} attributes fail when a child component is accessed outside of the
composite component (i.e. in action listeners or other events)
---
Key: MYFACES-3283
URL: https://issues.apache.org/jira/browse/MYFACES-3283
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.0.7
Environment: Mac OS 10.6, Tomcat 7
Reporter: Kito D. Mann
Attachments: myfaces_cc_issue.war
If you reference a property of child component anywhere outside of the
composite's context (i.e. in an action method, a component system event
listener, etc.), the property will not be evaluated properly if the
expression is a composite component attribute (i.e. #{cc.attrs.property}).
This is because the EL evaluation code can't find the parent composite
component.
For example, consider the composite component:
?xml version=1.0?
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:composite=http://java.sun.com/jsf/composite;
composite:interface
composite:attribute name=label /
composite:attribute name=value required=true /
/composite:interface
composite:implementation
h:outputLabel for=input value=#{cc.attrs.label} /
h:inputText id=input value=#{cc.attrs.value} /
/composite:implementation
/html
The calling page:
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:ui=http://java.sun.com/jsf/facelets;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:ez=http://java.sun.com/jsf/composite/demo;
h:head/h:head
h:body
h:form id=form
h:messages /
ez:input id=composite label=Enter something:
value=#{testBean.value} /
h:commandButton value=Submit
action=#{testBean.testCcAttribute} /
/h:form
/h:body
/html
Here's testBean.testCcAttribute():
public String testCcAttribute() {
HtmlInputText input =
(HtmlInputText)FacesContext.getCurrentInstance().getViewRoot().findComponent(form:composite:input);
UIComponent composite =
FacesContext.getCurrentInstance().getViewRoot().findComponent(form:composite);
String message = Input control label attribute is: +
input.getLabel() + ; Composite label attribute is: +
composite.getAttributes().get(label);
display(message);
return null;
}
This action method generates the following message:
Input control label attribute is: null; Composite label attribute is: Enter
something:
---
Full example WAR attached.
Note this is the same as the following issue with Mojarra:
http://java.net/jira/browse/JAVASERVERFACES-2009.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MYFACES-3283) #{cc.attr} attributes fail when a child component is accessed outside of the composite component (i.e. in action listeners or other events)
[
https://issues.apache.org/jira/browse/MYFACES-3283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13086685#comment-13086685
]
Kito D. Mann commented on MYFACES-3283:
---
I just took a look at the spec, and section 5.6.2.2 states the following:
5.6.2.2 Composite Component Attributes ELResolver
This ELResolver makes it so expressions that refer to the attributes of a
composite component get correctly evaluated.
For example, the expression #{cc.attrs.usernameLabel} says, “find the current
composite component, call its
getAttributes() method, within the returned Map look up the value under the key
“usernameLable”. If the value is
a ValueExpression, call getValue() on it and the result is returned as the
evaluation of the expression.
Otherwise, if the value is not a ValueExpression the value itself is returned
as the evaluation of the expression.”
It goes on to define the specific behavior of getValue():
If base is non-null, is an instance of UIComponent,
is a composite component, and property is non-null
and is equal to the string “attrs”, return a Map
implementation with the following characteristics.
Wrap the attributes map of the composite component
and delegate all calls to the composite component
attributes map with the following exceptions:
Only get() and put() are required to be supported.
get(): if the result of calling get() on the
component attributes map is null, and a default
value was declared in the composite component
metadata, the value will be a ValueExpression.
Evaluate it and return it. Otherwise, simply return
the value from the component attributes map.
put(): Call getValueExpression() on the component.
If this returns non-null, call setValue() on it,
passing the value argument as the last argument.
Otherwise, simply call through to put on the
component attributes map.
The Map implementation must also implement the
interface
javax.faces.el.CompositeComponentExpressionHolder.
Otherwise, take no action.
Nowhere in here does it say this should only work in the context of a tree
visit. The only ambiguous statement is current composite component. In the
Implicit EL Resolver description (section 5.6.2.1) you can find the following:
cc - the current composite component relative to the declaring page in which
the expression appears.
The current composite component can be considered the value returned from
UIComponent.getCurrentCompositeComponent(), which has this description:
Returns the closest ancestor component relative to getCurrentComponent that is
a composite component, or null if no such component is exists.
UIComponent.getCurrentComponent() is described as follows:
Returns the UIComponent instance that is currently being processed.
So, this does imply a tree traversal. It just doesn't make sense from a
developer's perspective...
#{cc.attr} attributes fail when a child component is accessed outside of the
composite component (i.e. in action listeners or other events)
---
Key: MYFACES-3283
URL: https://issues.apache.org/jira/browse/MYFACES-3283
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 2.0.7
Environment: Mac OS 10.6, Tomcat 7
Reporter: Kito D. Mann
Attachments: myfaces_cc_issue.war
If you reference a property of child component anywhere outside of the
composite's context (i.e. in an action method, a component system event
listener, etc.), the property will not be evaluated properly if the
expression is a composite component attribute (i.e. #{cc.attrs.property}).
This is because the EL evaluation code can't find the parent composite
component.
For example, consider the composite component:
?xml version=1.0?
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:composite=http://java.sun.com/jsf/composite;
composite:interface
composite:attribute name=label /
composite:attribute name=value required=true /
/composite:interface
composite:implementation
h:outputLabel for=input value=#{cc.attrs.label} /
h:inputText id=input value=#{cc.attrs.value} /
/composite:implementation
/html
The calling page:
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:ui=http://java.sun.com/jsf/facelets;
xmlns:h=http://java.sun.com/jsf/html;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:ez=http://java.sun.com/jsf/composite/demo;
h:head/h:head
h:body
h:form id=form
h:messages /
ez:input id=composite label=Enter something:
value=#{testBean.value}
