December 2013 - richfaces-issues - Jboss List Archives

[JBoss JIRA] (RF-13434) archetypes: change the namespace of richfaces components

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13434?page=com.atlassian.jira.plugin.s... ] Brian Leathem reassigned RF-13434: ---------------------------------- Assignee: Brian Leathem > archetypes: change the namespace of richfaces components > -------------------------------------------------------- > > Key: RF-13434 > URL: https://issues.jboss.org/browse/RF-13434 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: archetype > Affects Versions: 5.0.0.Alpha2 > Reporter: Jiří Štefek > Assignee: Brian Leathem > Priority: Critical > Fix For: 5.0.0.Alpha2 > > > After RF-13143 the namespace of RF 5 components has changed to {{http://richfaces.org}} but all archetypes use the old one. -- 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

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (RF-13435) extendedatatable: Scrolling position is lost after submit

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13435?page=com.atlassian.jira.plugin.s... ] Brian Leathem updated RF-13435: ------------------------------- Fix Version/s: 5-Tracking > extendedatatable: Scrolling position is lost after submit > --------------------------------------------------------- > > Key: RF-13435 > URL: https://issues.jboss.org/browse/RF-13435 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.3.4 > Environment: ALL > Reporter: Holger Walter > Labels: extendeddatatable, richfaces, scroll > Fix For: 5-Tracking > > > Issue is similar to RF-5312. > In EDT, the current scrolling position is lost (reset to 0) after a submit. > Steps to reproduce: > 1. Use the showcase for the EDT(version 4.3.4) > 2. Adapt the xhtml file by adding a simple submit button ( <h:commandButton value="Submit" />) > 3. Activate the 'ajax loading' checkbox > 4. Scroll down in the table > 5. Press the new submit button > 6. The scrolling position is lost > This might sound as a minor problem, but in case of using the EDT with ajax data loading, a user can scroll quite far until he may find the row on which he wants to do some actions. If the scrolling position is reset to 0 after each submit, it gets quite tedious for a user scrolling every time to this old position in the table. > I've seen that the current position is already stored in componentState, but unfortunately it is getting reset on submit. > I already tried a workaround, by using the 'onready' event of the EDT after a submit to trigger scrolling to the desired position with javascript but this does not work reliably on one hand, and triggers an additional ajax call which may cause that messages in h:messages are lost. -- 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

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (RF-13434) archetypes: change the namespace of richfaces components

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13434?page=com.atlassian.jira.plugin.s... ] Brian Leathem updated RF-13434: ------------------------------- Fix Version/s: 5.0.0.Alpha2 > archetypes: change the namespace of richfaces components > -------------------------------------------------------- > > Key: RF-13434 > URL: https://issues.jboss.org/browse/RF-13434 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: archetype > Affects Versions: 5.0.0.Alpha2 > Reporter: Jiří Štefek > Priority: Critical > Fix For: 5.0.0.Alpha2 > > > After RF-13143 the namespace of RF 5 components has changed to {{http://richfaces.org}} but all archetypes use the old one. -- 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

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (RF-13436) Upgrade CKEditor to 4.3

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13436?page=com.atlassian.jira.plugin.s... ] Brian Leathem updated RF-13436: ------------------------------- Fix Version/s: 5-Tracking > Upgrade CKEditor to 4.3 > ----------------------- > > Key: RF-13436 > URL: https://issues.jboss.org/browse/RF-13436 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 4.3.4, 5.0.0.Alpha1 > Reporter: barbara b > Labels: rich_editor > Fix For: 5-Tracking > > > All current versions of Richfaces are working with CKEditor 3.6.6. Would it be possible to make an upgrade of CKEditor to a version 4.3? Some plugins for CKEditor are only working with the 4.X versions of the editor. -- 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

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (RF-13432) Upgrade framework build to JSF 2.2

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/RF-13432?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč resolved RF-13432. ----------------------------- Resolution: Done https://github.com/richfaces/richfaces/commit/4437b869f325c54f43023be8f1d... > Upgrade framework build to JSF 2.2 > ---------------------------------- > > Key: RF-13432 > URL: https://issues.jboss.org/browse/RF-13432 > Project: RichFaces > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: third-party > Affects Versions: 5.0.0.Alpha3 > Reporter: Lukáš Fryč > Fix For: 5.0.0.Alpha3 > > -- 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

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (RF-13432) Upgrade framework build to JSF 2.2

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/RF-13432?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč reassigned RF-13432: ------------------------------- Assignee: Lukáš Fryč > Upgrade framework build to JSF 2.2 > ---------------------------------- > > Key: RF-13432 > URL: https://issues.jboss.org/browse/RF-13432 > Project: RichFaces > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: third-party > Affects Versions: 5.0.0.Alpha3 > Reporter: Lukáš Fryč > Assignee: Lukáš Fryč > Fix For: 5.0.0.Alpha3 > > -- 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

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (RF-13437) contextMenu: support hiding by clicking outside only

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13437?page=com.atlassian.jira.plugin.s... ] Brian Leathem updated RF-13437: ------------------------------- Fix Version/s: 5-Tracking > contextMenu: support hiding by clicking outside only > ---------------------------------------------------- > > Key: RF-13437 > URL: https://issues.jboss.org/browse/RF-13437 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-menu > Reporter: Lutz Ulrich > Priority: Minor > Fix For: 5-Tracking > > > Currently (until version 4.3.4), context menus always disappear when the mouse cursor is moved outside the menu. It should be possible to restrict hiding the menu when the user clicks somewhere else, like in many other applications, like Windows Explorer. > I was able to achieve this behavior by unbinding the event handler for mouseleave via extra scripting. > {{RichFaces.Event.unbindById(menu.id, 'mouseleave');}} > (Note that the code only prevents hiding the main menu on mouseleave. > Sub-menus / menuGroups are still closed on mouseleave.) > But it would be better if the contextMenu would support an attribute for turning on 'hide by outside click only'. > -- 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

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (RF-13432) Upgrade framework build to JSF 2.2

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/RF-13432?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč updated RF-13432: ---------------------------- Sprint: 5.0.0.Alpha3 - Sprint 1 > Upgrade framework build to JSF 2.2 > ---------------------------------- > > Key: RF-13432 > URL: https://issues.jboss.org/browse/RF-13432 > Project: RichFaces > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: third-party > Affects Versions: 5.0.0.Alpha3 > Reporter: Lukáš Fryč > Fix For: 5.0.0.Alpha3 > > -- 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

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (RF-13437) contextMenu: support hiding by clicking outside only

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13437?page=com.atlassian.jira.plugin.s... ] Brian Leathem commented on RF-13437: ------------------------------------ A reasonable request. Thanks for taking the time to fill out a Feature request jira. > contextMenu: support hiding by clicking outside only > ---------------------------------------------------- > > Key: RF-13437 > URL: https://issues.jboss.org/browse/RF-13437 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-menu > Reporter: Lutz Ulrich > Priority: Minor > Fix For: 5-Tracking > > > Currently (until version 4.3.4), context menus always disappear when the mouse cursor is moved outside the menu. It should be possible to restrict hiding the menu when the user clicks somewhere else, like in many other applications, like Windows Explorer. > I was able to achieve this behavior by unbinding the event handler for mouseleave via extra scripting. > {{RichFaces.Event.unbindById(menu.id, 'mouseleave');}} > (Note that the code only prevents hiding the main menu on mouseleave. > Sub-menus / menuGroups are still closed on mouseleave.) > But it would be better if the contextMenu would support an attribute for turning on 'hide by outside click only'. > -- 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

10 years, 4 months

1
0
0 / 0

[JBoss JIRA] (RF-13248) Switch RichFaces smoke tests to run on WildFly 8 by default

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/RF-13248?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč commented on RF-13248: --------------------------------- Some smoke tests still fails on WildFly 8.0, thus I'm postponing a switch to WildFly 8.0 as a default container. Feature branch: https://github.com/richfaces/richfaces/tree/RF-13248-smoke-tests-on-wildf... > Switch RichFaces smoke tests to run on WildFly 8 by default > ----------------------------------------------------------- > > Key: RF-13248 > URL: https://issues.jboss.org/browse/RF-13248 > Project: RichFaces > Issue Type: Task > Security Level: Public(Everyone can see) > Components: component > Affects Versions: 5.0.0.Alpha2 > Reporter: Lukáš Fryč > Assignee: Lukáš Fryč > Labels: jsf22 > Fix For: 5.0.0.Alpha3 > > Original Estimate: 15 minutes > Remaining Estimate: 15 minutes > > With start of WildFly Beta/CR release chain, we can switch our tests consume it, it means: > * tweaking TravisCI configuration > Note that tests have problem to pass on WildFly Beta1: > {code} > Tests run: 34, Failures: 1, Errors: 16, Skipped: 1 > {code} > so we need to analyze a cause of the failure first. -- 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

10 years, 4 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 December 2013