August 2013 - richfaces-issues - Jboss List Archives

[JBoss JIRA] (RF-13127) onvalid and oninvalide pass wrong element when using rich:element with String field

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13127?page=com.atlassian.jira.plugin.s... ] Brian Leathem updated RF-13127: ------------------------------- Labels: waiting_on_user (was: ) > onvalid and oninvalide pass wrong element when using rich:element with String field > ----------------------------------------------------------------------------------- > > Key: RF-13127 > URL: https://issues.jboss.org/browse/RF-13127 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-validators > Affects Versions: 4.3.3 > Reporter: Louis Parisi > Labels: waiting_on_user > > I have a bean iterated in a datatable. Using the rich:validator on fields in the bean I am executing javascript when a field is validated and apply styling based on valid or invalid state. The code below returns the correct element when the underlying field is a BigDecimal but always returns the element from row zero when the field is a String. If I just reference a String vs. BigDecimal and display the element passed to the javascript I get form:myTable:4:myField for a BigDecimal field and always form:myTable:0:myField no matter the row for a String field. > {code} > <h:inputText value="#\{myBean.myField}" id="myField"> > <rich:validator oninvalid="valueModifiedAndError(#\{rich:element('myField')})" > onvalid="valueModified(#\{rich:element('myField')})"/> > </h:inputText> > {code} > Some other tests I did while trying to debug are: > * I passed the rowKeyVar to a javascript method in the onvalid event and it passed the correct row for a BigDecimal and always zero for a String field. > * The oncomplete event of the validator does not seem to fire for a String field but does for a BigDecimal field. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (RF-13127) onvalid and oninvalide pass wrong element when using rich:element with String field

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13127?page=com.atlassian.jira.plugin.s... ] Brian Leathem updated RF-13127: ------------------------------- Description: I have a bean iterated in a datatable. Using the rich:validator on fields in the bean I am executing javascript when a field is validated and apply styling based on valid or invalid state. The code below returns the correct element when the underlying field is a BigDecimal but always returns the element from row zero when the field is a String. If I just reference a String vs. BigDecimal and display the element passed to the javascript I get form:myTable:4:myField for a BigDecimal field and always form:myTable:0:myField no matter the row for a String field. {code} <h:inputText value="#\{myBean.myField}" id="myField"> <rich:validator oninvalid="valueModifiedAndError(#\{rich:element('myField')})" onvalid="valueModified(#\{rich:element('myField')})"/> </h:inputText> {code} Some other tests I did while trying to debug are: * I passed the rowKeyVar to a javascript method in the onvalid event and it passed the correct row for a BigDecimal and always zero for a String field. * The oncomplete event of the validator does not seem to fire for a String field but does for a BigDecimal field. was: I have a bean iterated in a datatable. Using the rich:validator on fields in the bean I am executing javascript when a field is validated and apply styling based on valid or invalid state. The code below returns the correct element when the underlying field is a BigDecimal but always returns the element from row zero when the field is a String. If I just reference a String vs. BigDecimal and display the element passed to the javascript I get form:myTable:4:myField for a BigDecimal field and always form:myTable:0:myField no matter the row for a String field. <h:inputText value="#\{myBean.myField}" id="myField"> <rich:validator oninvalid="valueModifiedAndError(#\{rich:element('myField')})" onvalid="valueModified(#\{rich:element('myField')})"/> </h:inputText> Some other tests I did while trying to debug are: - I passed the rowKeyVar to a javascript method in the onvalid event and it passed the correct row for a BigDecimal and always zero for a String field. - The oncomplete event of the validator does not seem to fire for a String field but does for a BigDecimal field. > onvalid and oninvalide pass wrong element when using rich:element with String field > ----------------------------------------------------------------------------------- > > Key: RF-13127 > URL: https://issues.jboss.org/browse/RF-13127 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-validators > Affects Versions: 4.3.3 > Reporter: Louis Parisi > > I have a bean iterated in a datatable. Using the rich:validator on fields in the bean I am executing javascript when a field is validated and apply styling based on valid or invalid state. The code below returns the correct element when the underlying field is a BigDecimal but always returns the element from row zero when the field is a String. If I just reference a String vs. BigDecimal and display the element passed to the javascript I get form:myTable:4:myField for a BigDecimal field and always form:myTable:0:myField no matter the row for a String field. > {code} > <h:inputText value="#\{myBean.myField}" id="myField"> > <rich:validator oninvalid="valueModifiedAndError(#\{rich:element('myField')})" > onvalid="valueModified(#\{rich:element('myField')})"/> > </h:inputText> > {code} > Some other tests I did while trying to debug are: > * I passed the rowKeyVar to a javascript method in the onvalid event and it passed the correct row for a BigDecimal and always zero for a String field. > * The oncomplete event of the validator does not seem to fire for a String field but does for a BigDecimal field. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (RF-13128) Automatic rendering of transitive dependencies

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13128?page=com.atlassian.jira.plugin.s... ] Brian Leathem updated RF-13128: ------------------------------- Fix Version/s: 5-Tracking > Automatic rendering of transitive dependencies > ---------------------------------------------- > > Key: RF-13128 > URL: https://issues.jboss.org/browse/RF-13128 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: architectural, base functionality, core > Affects Versions: 5.0.0.Alpha1 > Reporter: Juraj Húska > Priority: Minor > Fix For: 5-Tracking > > > Consider please following pseudo code for using {{r:dataScroller}}: > {code:xml} > <r:dataScroller id="topScroller" for="table" /> > <r:dataTable> > <r:column>Blah</r:column> > <f:facet name="footer"> > <r:dataScroller render="topScroller"/> > </f:facet> > </r:dataTable> > {code} > When the bottom scroller is changed, then the top scroller is as well, because the bottom one has {{render}} attribute set correctly. > It would be IMHO nice addition, if this had been done automatically. The {{r:dataTable}} may know which scroller is bound to it, and update it automatically. > [~lfryc] idea for general implementation: > ??Support for it does not exist in JSF/RF right now. But it can be added. If you have {{render="A"}}, then also X would be rendered, where X are all transitive dependencies, which make the component. A component can have an interface, to which you can register those explicit targets. Datascroller would use such interface.?? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (RF-13113) org.richfaces.cdk.parent depends on older org.jboss.spec.jboss-javaee-web-6.0

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13113?page=com.atlassian.jira.plugin.s... ] Brian Leathem reassigned RF-13113: ---------------------------------- Assignee: Lukáš Fryč (was: Brian Leathem) > org.richfaces.cdk.parent depends on older org.jboss.spec.jboss-javaee-web-6.0 > ----------------------------------------------------------------------------- > > Key: RF-13113 > URL: https://issues.jboss.org/browse/RF-13113 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: cdk > Reporter: Tomas Repel > Assignee: Lukáš Fryč > Fix For: 4.3.4 > > Original Estimate: 30 minutes > Remaining Estimate: 30 minutes > > Description of problem: > org.richfaces.cdk.parent depends on older org.jboss.spec.jboss-javaee-web-6.0:3.0.1.Final-redhat-1, which is available only in jboss-eap-6.0.1-maven repository. > This causes failure when building Seam distribution from sources. In EAP 6.1 repository there is available org.jboss.spec : jboss-javaee-web-6.0 : 3.0.2.Final-redhat-3 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (RF-13059) Richfaces quickstart README files contain links that to be updated

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13059?page=com.atlassian.jira.plugin.s... ] Brian Leathem reassigned RF-13059: ---------------------------------- Assignee: Brian Leathem > Richfaces quickstart README files contain links that to be updated > ------------------------------------------------------------------ > > Key: RF-13059 > URL: https://issues.jboss.org/browse/RF-13059 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: examples > Reporter: Sande Gilda > Assignee: Brian Leathem > Fix For: 4.3.4 > > Original Estimate: 15 minutes > Remaining Estimate: 15 minutes > > A fix to the dist/release-utils.sh script that creates HTML from the markdown files was fixed to automatically generate anchors. More information can be found in this JIRA: > https://issues.jboss.org/browse/JDF-358 > The quickstart README files were updated to remove the hard-coded anchors and use the one automatically generated when linking to other README sections. > The RichFaces quickstarts were modified in the jboss-jdf quickstart repository with this pull: https://github.com/jboss-jdf/jboss-as-quickstart/pull/529 > The commit is here: > https://github.com/sgilda/jboss-as-quickstart/commit/aa710d72a31d49f11e62... > You need to update your repository with the same changes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (RF-13038) Command button/link: attribute tabindex missing

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13038?page=com.atlassian.jira.plugin.s... ] Brian Leathem reassigned RF-13038: ---------------------------------- Assignee: Brian Leathem > Command button/link: attribute tabindex missing > ----------------------------------------------- > > Key: RF-13038 > URL: https://issues.jboss.org/browse/RF-13038 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-a4j-core > Affects Versions: 4.3.2, 5.0.0.Alpha1 > Reporter: Pavol Pitonak > Assignee: Brian Leathem > Priority: Minor > Fix For: 4.3.4 > > Original Estimate: 15 minutes > Remaining Estimate: 15 minutes > > Components command button and command link don't have attribute "tabindex", however, when it's set on the component, it's rendered correctly. This issue is similar to one for accesskey attribute (RF-12846). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (RF-13058) Kitchensink Archetype: JSF community site link doesn't work

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13058?page=com.atlassian.jira.plugin.s... ] Brian Leathem reassigned RF-13058: ---------------------------------- Assignee: Brian Leathem > Kitchensink Archetype: JSF community site link doesn't work > ----------------------------------------------------------- > > Key: RF-13058 > URL: https://issues.jboss.org/browse/RF-13058 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: archetype > Affects Versions: 4.3.2, 5.0.0.Alpha1 > Reporter: Jan Papousek > Assignee: Brian Leathem > Fix For: 4.3.4 > > Original Estimate: 15 minutes > Remaining Estimate: 15 minutes > > linked http://www.javaserverfaces.org/ site is not active anymore -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (RF-13016) Archetypes should be removed from 4.3 build and dist

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13016?page=com.atlassian.jira.plugin.s... ] Brian Leathem reassigned RF-13016: ---------------------------------- Assignee: Brian Leathem > Archetypes should be removed from 4.3 build and dist > ---------------------------------------------------- > > Key: RF-13016 > URL: https://issues.jboss.org/browse/RF-13016 > Project: RichFaces > Issue Type: Task > Security Level: Public(Everyone can see) > Components: archetype > Affects Versions: 4.3.2 > Reporter: Lukáš Fryč > Assignee: Brian Leathem > Fix For: 4.3.4 > > Original Estimate: 15 minutes > Remaining Estimate: 15 minutes > > Archetypes will now have independent release cycle. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (RF-13017) richfaces-bom 4.3.2.Final, JSF-API 2.1.0 not compatible

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13017?page=com.atlassian.jira.plugin.s... ] Brian Leathem reassigned RF-13017: ---------------------------------- Assignee: Brian Leathem > richfaces-bom 4.3.2.Final, JSF-API 2.1.0 not compatible > ------------------------------------------------------- > > Key: RF-13017 > URL: https://issues.jboss.org/browse/RF-13017 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: build/distribution > Affects Versions: 4.3.2 > Reporter: Himanshu Bhardwaj > Assignee: Brian Leathem > Fix For: 4.3.4 > > Original Estimate: 15 minutes > Remaining Estimate: 15 minutes > > In the bom of RichFaces, the version of JSF-API being used is > {code} > <version.com.sun.faces.jsf-api>2.1.0</version.com.sun.faces.jsf-api> > {code} > > but the version of JSF-IMPL put in use is: > {code} > <version.org.jboss.javax.faces.jsf-impl>2.1.19-jbossorg-1</version.org.jboss.javax.faces.jsf-impl> > {code} > > Both the version don't seem to go together. Got the following stack-trace: > > {code} > SEVERE: ContainerBase.addChild: start: > org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/abc]] > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154) > at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) > at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) > at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633) > at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:977) > at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1655) > at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) > at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) > at java.util.concurrent.FutureTask.run(Unknown Source) > at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) > at java.lang.Thread.run(Unknown Source) > Caused by: java.lang.NullPointerException > at com.sun.faces.config.InitFacesContext.cleanupInitMaps(InitFacesContext.java:281) > at com.sun.faces.config.InitFacesContext.<init>(InitFacesContext.java:107) > at com.sun.faces.config.FacesInitializer.onStartup(FacesInitializer.java:115) > at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5274) > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) > ... 11 more > > > May 21, 2013 11:30:43 AM org.apache.catalina.startup.HostConfig deployWAR > SEVERE: Error deploying web application archive F:\DevTools\apache-tomcat-7.0.34\webapps\abc.war > java.lang.IllegalStateException: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/abc]] > at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:904) > at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) > at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633) > at org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:977) > at org.apache.catalina.startup.HostConfig$DeployWar.run(HostConfig.java:1655) > at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) > at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) > at java.util.concurrent.FutureTask.run(Unknown Source) > at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) > at java.lang.Thread.run(Unknown Source) > {code} > > I had to manually delete the 2.1.0 jsf-api jar from the war file and copy 2.1.19, with this I was able to bypass this error. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

[JBoss JIRA] (RF-13119) kitchensink-rf test-ds.xml does not use a unique datasource JNDI name

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13119?page=com.atlassian.jira.plugin.s... ] Brian Leathem reassigned RF-13119: ---------------------------------- Assignee: Brian Leathem > kitchensink-rf test-ds.xml does not use a unique datasource JNDI name > --------------------------------------------------------------------- > > Key: RF-13119 > URL: https://issues.jboss.org/browse/RF-13119 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: examples > Reporter: Sande Gilda > Assignee: Brian Leathem > Fix For: 4.3.4 > > Original Estimate: 30 minutes > Remaining Estimate: 30 minutes > > The richfaces-quickstarts/kitchensink-rf/src/test/resources/test-ds.xml uses the same datasource JNDI name and connection URL that the kitchensink quickstart test file uses: > <datasource jndi-name="java:jboss/datasources/KitchensinkQuickstartTestDS" > <connection-url>jdbc:h2:mem:kitchensink-quickstart-test;DB_CLOSE_DELAY=-1</connection-url> > This should be changed to a unique name, for example: > <datasource jndi-name="java:jboss/datasources/KitchensinkrfQuickstartTestDS" > <connection-url>jdbc:h2:mem:kitchensink-rf-quickstart-test;DB_CLOSE_DELAY=-1</connection-url> -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 3 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

richfaces-issues August 2013