December 2013 - richfaces-issues - Jboss List Archives

[JBoss JIRA] (RF-13230) Resetting table state on extendedDataTable does not reset table when using ajax re-render

by Matej Novotny (JIRA)

[ https://issues.jboss.org/browse/RF-13230?page=com.atlassian.jira.plugin.s... ] Matej Novotny commented on RF-13230: ------------------------------------ [~ibenjes], I tried using your example but came across several problems. I made some changes to make the example fully working. The function sort() is working but requires two arguments, column ID and sort order (eg. descending/descending). The conversation scoped bean you are using does not seem to have any effect as you do not start/end conversation eg. it behaves as view scoped if I am not mistaken - still I used it to reproduce the problem. Also I removed the Logger as it is not needed for the example. Now to the result. I used Metamer (our testing app) with 4.3.3.Final and current 4.3.x. The bug described in the forum can be found in *both* versions, so it is *not regression*. In both version there is a problem you just described that the state does not affect first page unless you use data scroller. Without data scroller everything works correctly. I will add a tests for this issue to 4.3.x and also check it in version 5 and report further details. By the way, the forum link you gave leads to RF-13226 and not this issue, is that a copy of this isue then? (problem seems pretty much the same) > Resetting table state on extendedDataTable does not reset table when using ajax re-render > ----------------------------------------------------------------------------------------- > > Key: RF-13230 > URL: https://issues.jboss.org/browse/RF-13230 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-tables > Affects Versions: 4.3.4 > Reporter: Immo Benjes > Assignee: Matej Novotny > Labels: regression > Fix For: 4.3.5 > > > On a extendedDataTable resetting the table state and then re-rendering the table via ajax does not work, the table still shows the custom column ordering and column width. Only when reloading the complete page, the table is displayed in its default form. > To reproduce: > rich:extendedDataTable with tableState help in a (e.g. Seam conversation scoped bean). Change the column ordering, now call an ajax method that resets the table state to null or an empty string. Re-render the table after completion. The column ordering stays the same. > This used to work on RF 4.3.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

10 years, 5 months

1
0
0 / 0

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

by barbara b (JIRA)

barbara b created RF-13436: ------------------------------ Summary: 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: 5.0.0.Alpha1, 4.3.4 Reporter: barbara b 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, 5 months

1
0
0 / 0

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

by Jiří Štefek (JIRA)

[ https://issues.jboss.org/browse/RF-13434?page=com.atlassian.jira.plugin.s... ] Jiří Štefek updated RF-13434: ----------------------------- Description: After RF-13143 the namespace of RF 5 components has changed to {{http://richfaces.org}} but all archetypes use the old one. (was: After RF-13143 the namespace of RF 5 components has changed to {{http://richfaces.org}}) > 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 > > 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, 5 months

1
0
0 / 0

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

by Holger Walter (JIRA)

[ https://issues.jboss.org/browse/RF-13435?page=com.atlassian.jira.plugin.s... ] Holger Walter commented on RF-13435: ------------------------------------ I tested only with 4.3.4. If it helps I can test with older versions e.g. 4.2.3 as well and give you feedback. > 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 > > 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, 5 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 commented on RF-13435: ------------------------------------ [~wlh] is this a regression? Did it work for you as expected in previous 4.3.x versions? > 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 > > 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, 5 months

1
0
0 / 0

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

by Holger Walter (JIRA)

Holger Walter created RF-13435: ---------------------------------- Summary: 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 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, 5 months

1
0
0 / 0

[JBoss JIRA] (RF-13370) Charts - server-side improvements

by Pavol Pitonak (JIRA)

[ https://issues.jboss.org/browse/RF-13370?page=com.atlassian.jira.plugin.s... ] Pavol Pitonak closed RF-13370. ------------------------------ > Charts - server-side improvements > --------------------------------- > > Key: RF-13370 > URL: https://issues.jboss.org/browse/RF-13370 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-output > Reporter: Lukáš Macko > Assignee: Lukáš Macko > Fix For: 5.0.0.Alpha2 > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > * rename attribute *clickListener* in chart and series tag to *plotClickListner* > * send request to server only if a server-side listener is attached > * particular series server-side listeners (called only for particular series events) > * server-side listener method is not called when Bean is annotated with @Named (listener is called properly for @MangedBean) -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (RF-13129) Bind Widget Bridge reference to the DOM

by Jiří Štefek (JIRA)

[ https://issues.jboss.org/browse/RF-13129?page=com.atlassian.jira.plugin.s... ] Jiří Štefek closed RF-13129. ---------------------------- verified, closing. > Bind Widget Bridge reference to the DOM > --------------------------------------- > > Key: RF-13129 > URL: https://issues.jboss.org/browse/RF-13129 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: core > Reporter: Lukáš Fryč > Assignee: Lukáš Fryč > Fix For: 5.0.0.Alpha2 > > Original Estimate: 30 minutes > Remaining Estimate: 30 minutes > > Following alghoritm looks for the RichFaces component root and re-directs event source to this root: > https://github.com/richfaces/richfaces/blob/master/framework/src/main/res... > However bridge code isn't registered to the DOM in the way RichFaces 4 using BaseComponent are. > I suggest to bind the reference to the DOM using jQuery.data. -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (RF-13399) RichFaces can't be built with Maven 3.1.1

by Pavol Pitonak (JIRA)

[ https://issues.jboss.org/browse/RF-13399?page=com.atlassian.jira.plugin.s... ] Pavol Pitonak closed RF-13399. ------------------------------ I can't reproduce anymore > RichFaces can't be built with Maven 3.1.1 > ----------------------------------------- > > Key: RF-13399 > URL: https://issues.jboss.org/browse/RF-13399 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: build/distribution > Affects Versions: 5.0.0.Alpha2 > Reporter: Lukáš Fryč > Assignee: Lukáš Fryč > Fix For: 5.0.0.Alpha2 > > -- 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, 5 months

1
0
0 / 0

[JBoss JIRA] (RF-13181) Autocomplete: suggestion list is not valid HTML code

by Jiří Štefek (JIRA)

[ https://issues.jboss.org/browse/RF-13181?page=com.atlassian.jira.plugin.s... ] Jiří Štefek closed RF-13181. ---------------------------- verified, closing. > Autocomplete: suggestion list is not valid HTML code > ---------------------------------------------------- > > Key: RF-13181 > URL: https://issues.jboss.org/browse/RF-13181 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-input > Affects Versions: 5.0.0.Alpha2 > Environment: RichFaces 5.0.0-SNAPSHOT > Metamer 5.0.0-SNAPSHOT > Mojarra 2.1.19 > JBoss AS 7.2.0.Final-redhat-8 > Java(TM) SE Runtime Environment 1.7.0_04-b20 @ Linux > Chrome 29.0.1547.65 @ Linux x86_64 > Reporter: Pavol Pitonak > Assignee: Lukáš Fryč > Priority: Critical > Fix For: 5.0.0.Alpha2 > > Original Estimate: 15 minutes > Remaining Estimate: 15 minutes > > # deploy Metamer and open http://localhost:8080/metamer/faces/components/richAutocomplete/autocompl... > # type "a" into input > # check suggestion list's markup > result: > * Autocomplete generates an unsorted list (ul) with several list items (li), one for each suggestion. However, inside each li, there is yet another li which is not allowed by HTML. > {code:xml} > <ul class="ui-autocomplete ui-menu ui-widget ui-widget-content ui-corner-all" id="ui-id-1" tabindex="0" style="z-index: 1; display: block; top: 237.0142364501953px; left: 10px; width: 161px;"> > <li class="ui-menu-item" role="presentation"> > <a id="ui-id-7" class="ui-corner-all" tabindex="-1"> > <li>Alabama</li> > </a> > </li> > ... > </ul> > {code} -- 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, 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 December 2013