June 2013 - richfaces-issues - Jboss List Archives

[JBoss JIRA] (RF-13062) r:validator stops working

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13062?page=com.atlassian.jira.plugin.s... ] Brian Leathem updated RF-13062: ------------------------------- Fix Version/s: 5.0.0.Alpha2 > r:validator stops working > ------------------------- > > Key: RF-13062 > URL: https://issues.jboss.org/browse/RF-13062 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-validators > Affects Versions: 5.0.0.Alpha1 > Reporter: Juergen Zimmermann > Assignee: Pavol Pitonak > Fix For: 5.0.0.Alpha2 > > > I just tried r:validator with the current snapshot for WildFly 8.0.0.Alpha2 (changed Mojarra 2.2.0 to 2.1.23). However, if I'm doing a wrong input nothing happens. No error message, no stacktrace, just nothing. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (RF-13063) RichFacesInputNumberSlider setValueByDragging

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13063?page=com.atlassian.jira.plugin.s... ] Brian Leathem reassigned RF-13063: ---------------------------------- Assignee: Pavol Pitonak [~ppitonak] Can you assess and schedule accordingly? > RichFacesInputNumberSlider setValueByDragging > --------------------------------------------- > > Key: RF-13063 > URL: https://issues.jboss.org/browse/RF-13063 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: qe > Affects Versions: 4.3.2 > Reporter: Bernard Labno > Assignee: Pavol Pitonak > Priority: Minor > > In richfaces-qa/page-fragments there is RichFacesInputNumberSlider fragment. It would be great to be able to test setting value as percentage of width implemented as dragging the handle. > One can do it like that: > {code} > ((JavascriptExecutor) GrapheneContext.getProxy()).executeScript("arguments[0].scrollIntoView(true);", weightSlider.getNumberSlider().getRoot()); > waitGui(); > final int width = weightSlider.getNumberSlider().getWidth(); > final int where = (int) (width * percentage); > final WebElement handle = weightSlider.getNumberSlider().getHandleElement(); > final Action action = new Actions(GrapheneContext.getProxy()).clickAndHold(handle) > .moveToElement(weightSlider.getNumberSlider().getRoot(), where, 0) > .release(handle) > .build(); > {code} > It is very important to bring component into view before dragging. > If you do not do that and component is very far to the right (you need to scroll to the right to see it) then calculations are wrong. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (RF-13064) custom popups for selects

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13064?page=com.atlassian.jira.plugin.s... ] Brian Leathem reassigned RF-13064: ---------------------------------- Assignee: Lukáš Fryč Is this in scope for the autocomplete client-side rewrite in 5.0.0.Alpha2? > custom popups for selects > ------------------------- > > Key: RF-13064 > URL: https://issues.jboss.org/browse/RF-13064 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-selects > Affects Versions: 4.3.2, 5-Tracking > Reporter: J W > Assignee: Lukáš Fryč > > The user should be able to define custom Items which will be visable in the Selection-List. An example for this are the current custom popup layouts for the autocomplete componente http://showcase.richfaces.org/richfaces/component-sample.jsf?demo=autocom... > It should be possible to define Title-Attributes for Items. A hirarchical grouping of the items should be also possible e.g: group citys by countrys. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (RF-13063) RichFacesInputNumberSlider setValueByDragging

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13063?page=com.atlassian.jira.plugin.s... ] Brian Leathem updated RF-13063: ------------------------------- Description: In richfaces-qa/page-fragments there is RichFacesInputNumberSlider fragment. It would be great to be able to test setting value as percentage of width implemented as dragging the handle. One can do it like that: {code} ((JavascriptExecutor) GrapheneContext.getProxy()).executeScript("arguments[0].scrollIntoView(true);", weightSlider.getNumberSlider().getRoot()); waitGui(); final int width = weightSlider.getNumberSlider().getWidth(); final int where = (int) (width * percentage); final WebElement handle = weightSlider.getNumberSlider().getHandleElement(); final Action action = new Actions(GrapheneContext.getProxy()).clickAndHold(handle) .moveToElement(weightSlider.getNumberSlider().getRoot(), where, 0) .release(handle) .build(); {code} It is very important to bring component into view before dragging. If you do not do that and component is very far to the right (you need to scroll to the right to see it) then calculations are wrong. was: In richfaces-qa/page-fragments there is RichFacesInputNumberSlider fragment. It would be great to be able to test setting value as percentage of width implemented as dragging the handle. One can do it like that: ((JavascriptExecutor) GrapheneContext.getProxy()).executeScript("arguments[0].scrollIntoView(true);", weightSlider.getNumberSlider().getRoot()); waitGui(); final int width = weightSlider.getNumberSlider().getWidth(); final int where = (int) (width * percentage); final WebElement handle = weightSlider.getNumberSlider().getHandleElement(); final Action action = new Actions(GrapheneContext.getProxy()).clickAndHold(handle) .moveToElement(weightSlider.getNumberSlider().getRoot(), where, 0) .release(handle) .build(); It is very important to bring component into view before dragging. If you do not do that and component is very far to the right (you need to scroll to the right to see it) then calculations are wrong. > RichFacesInputNumberSlider setValueByDragging > --------------------------------------------- > > Key: RF-13063 > URL: https://issues.jboss.org/browse/RF-13063 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: qe > Affects Versions: 4.3.2 > Reporter: Bernard Labno > Priority: Minor > > In richfaces-qa/page-fragments there is RichFacesInputNumberSlider fragment. It would be great to be able to test setting value as percentage of width implemented as dragging the handle. > One can do it like that: > {code} > ((JavascriptExecutor) GrapheneContext.getProxy()).executeScript("arguments[0].scrollIntoView(true);", weightSlider.getNumberSlider().getRoot()); > waitGui(); > final int width = weightSlider.getNumberSlider().getWidth(); > final int where = (int) (width * percentage); > final WebElement handle = weightSlider.getNumberSlider().getHandleElement(); > final Action action = new Actions(GrapheneContext.getProxy()).clickAndHold(handle) > .moveToElement(weightSlider.getNumberSlider().getRoot(), where, 0) > .release(handle) > .build(); > {code} > It is very important to bring component into view before dragging. > If you do not do that and component is very far to the right (you need to scroll to the right to see it) then calculations are wrong. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (RF-13065) r:calendar : German translation for "Today" is "Heute"

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13065?page=com.atlassian.jira.plugin.s... ] Brian Leathem updated RF-13065: ------------------------------- Fix Version/s: 5-Tracking > r:calendar : German translation for "Today" is "Heute" > ------------------------------------------------------ > > Key: RF-13065 > URL: https://issues.jboss.org/browse/RF-13065 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 5.0.0.Alpha1 > Reporter: Juergen Zimmermann > Fix For: 5-Tracking > > > Well, the translation of today is: Heute -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (RF-13066) a4j:ajax does not work with tomahawk radiobuttons

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13066?page=com.atlassian.jira.plugin.s... ] Brian Leathem updated RF-13066: ------------------------------- Fix Version/s: 5-Tracking > a4j:ajax does not work with tomahawk radiobuttons > ------------------------------------------------- > > Key: RF-13066 > URL: https://issues.jboss.org/browse/RF-13066 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 4.3.0.Final > Environment: a4j:ajax does not work inside a tomahawk radiobutton > Reporter: Andrea Martino > Labels: a4j:ajax > Fix For: 5-Tracking > > > for example the following code does not work: > {code} > <t:selectOneRadio id="myRadio" value="#{testtest.xxxEnum}" layout="spread"> > <s:enumItem enumValue="XXX" label="XXX" /> > <s:enumItem enumValue="YYY" label="YYY" /> > <a4j:ajax /> > </t:selectOneRadio> > <div class="ct-radio"> > <strong><t:radio for="myRadio" index="0"/></strong> > </div> > <div class="ct-radio"> > <strong><t:radio for="myRadio" index="1"/></strong> > </div> > {code} > If I replace <a4j:ajax/> by <f:ajax/> everything works as expected. I would like to user a4j:ajax instead of f:ajax because tooltips are not correctly refreshed when I use f:ajax (there should be already a bug opened for that). > PS: I'm using tomahawk 1.1.14 -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (RF-13067) forge plugin - package of RichBean is not updated according to top level package

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13067?page=com.atlassian.jira.plugin.s... ] Brian Leathem updated RF-13067: ------------------------------- Labels: forge (was: ) > forge plugin - package of RichBean is not updated according to top level package > -------------------------------------------------------------------------------- > > Key: RF-13067 > URL: https://issues.jboss.org/browse/RF-13067 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Jan Papousek > Labels: forge > > When a new project with top level package (e.g. "org.richfaces") is created and then richfaces plugin used to generate an example application, the generated RichBean is defined with wrong package "ca.bleathem.richfaces" (see https://github.com/richfaces/richfaces-forge-plugin/blob/master/src/main/...) -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (RF-13067) forge plugin - package of RichBean is not updated according to top level package

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13067?page=com.atlassian.jira.plugin.s... ] Brian Leathem updated RF-13067: ------------------------------- Fix Version/s: 5-Tracking > forge plugin - package of RichBean is not updated according to top level package > -------------------------------------------------------------------------------- > > Key: RF-13067 > URL: https://issues.jboss.org/browse/RF-13067 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Reporter: Jan Papousek > Labels: forge > Fix For: 5-Tracking > > > When a new project with top level package (e.g. "org.richfaces") is created and then richfaces plugin used to generate an example application, the generated RichBean is defined with wrong package "ca.bleathem.richfaces" (see https://github.com/richfaces/richfaces-forge-plugin/blob/master/src/main/...) -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (RF-13070) mediaOutput: onblur and onfocus events are fired twice

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13070?page=com.atlassian.jira.plugin.s... ] Brian Leathem reassigned RF-13070: ---------------------------------- Assignee: Pavol Pitonak [~ppitonak] Is this a new bug with 5.0.0.Alpha1? > mediaOutput: onblur and onfocus events are fired twice > ------------------------------------------------------ > > Key: RF-13070 > URL: https://issues.jboss.org/browse/RF-13070 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 5.0.0.Alpha1 > Reporter: Jan Papousek > Assignee: Pavol Pitonak > -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (RF-13071) Undeploying Showcase from Tomcat6/7 can cause memory leak

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13071?page=com.atlassian.jira.plugin.s... ] Brian Leathem commented on RF-13071: ------------------------------------ Thanks Juraj. The showcase will get a refit in Alpha2/Alpha3. We'll see if this continues to be an issue after that. > Undeploying Showcase from Tomcat6/7 can cause memory leak > --------------------------------------------------------- > > Key: RF-13071 > URL: https://issues.jboss.org/browse/RF-13071 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-push/poll, showcase > Affects Versions: 4.1.0.Final, 5.0.0.Alpha1 > Reporter: Juraj Húska > Priority: Minor > Labels: memory_leak, performance > Fix For: 5-Tracking > > > When undeploying showcase from Tomcat 6/7 then following log is present on the server console: > {code} > SEVERE: The web application [/richfaces-showcase-tomcat6] appears to have started a thread named [Thread-0 (group:HornetQ-client-factory-threads-1831192424-1080990297)] but has failed to stop it. This is very likely to create a memory leak. > {code} > There is lot of such logs, just the _Thread-counter_ is changing. > * 11 such logs just with showcase deploying and then right after undeploying > * bit more when after deploying playing a little bit with {{r:push}} > IMHO it is not just warning. I am experiencing {{Out of Memory}} issues when testing on Tomcat. I need to use quite big {{Perm Gen}} and {{Heap size}} -- 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, 5 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 June 2013