September 2012 - richfaces-issues

[JBoss JIRA] (RF-12236) showcase - rich:extendedDataTable - re-sizing columns breaks horizontal scrolling

by Juraj Huska (JIRA)

Juraj Huska created RF-12236: -------------------------------- Summary: showcase - rich:extendedDataTable - re-sizing columns breaks horizontal scrolling Key: RF-12236 URL: https://issues.jboss.org/browse/RF-12236 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: component-tables, showcase Affects Versions: 4.2.2.Final Environment: richfaces showcase app container: JBoss AS 7.1.1.Final browsers: Chrome, Firefox Reporter: Juraj Huska Re-sizing columns on rich:extendedDataTable breaks horizontal scrolling. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

7
30
0 / 0

[JBoss JIRA] (RF-12255) kitchensink archetype - error message from server side validation not rendered correctly

by Juraj Huska (JIRA)

Juraj Huska created RF-12255: -------------------------------- Summary: kitchensink archetype - error message from server side validation not rendered correctly Key: RF-12255 URL: https://issues.jboss.org/browse/RF-12255 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: archetype, component-validators Affects Versions: 4.2.2.Final Environment: project generated from kitchensink archetype Reporter: Juraj Huska Priority: Minor Validation error from server side validation is not rendered correctly, the image with red cross is overlapped with the text part. Please take a look at the attached screenshot. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

3
12
0 / 0

[JBoss JIRA] (RF-12252) kitchensink archetype - creating already registered user throws server side error - it should be caught and user should be noticed

by Juraj Huska (JIRA)

Juraj Huska created RF-12252: -------------------------------- Summary: kitchensink archetype - creating already registered user throws server side error - it should be caught and user should be noticed Key: RF-12252 URL: https://issues.jboss.org/browse/RF-12252 Project: RichFaces Issue Type: Enhancement Security Level: Public (Everyone can see) Components: archetype Environment: project generated from kitchensink archetype Reporter: Juraj Huska Priority: Minor When creating an already registered user there is server side error, because of the not unique email: {code} javax.ejb.EJBException: javax.persistence.PersistenceException: org.hibernate.exception.ConstraintViolationException: Unique index or primary key violation: "CONSTRAINT_INDEX_8 ON PUBLIC.MEMBER(EMAIL)"; SQL statement: {code} The is also no error message rendered to the user. There should be some notice that such a user have been already registered. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

4
17
0 / 0

[JBoss JIRA] (RF-12474) rich:select with enableManuelInput="true": Validation message is not displayed when the submitted value is not on the list.

by Ilia Vassilev (JIRA)

Ilia Vassilev created RF-12474: ---------------------------------- Summary: rich:select with enableManuelInput="true": Validation message is not displayed when the submitted value is not on the list. Key: RF-12474 URL: https://issues.jboss.org/browse/RF-12474 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.2.2.Final Reporter: Ilia Vassilev Fix For: 4.Future Per RichFaces documentation [1]: "...If an invalid value is entered, it is highlighted as erroneous and validation messages appear with the submission..." The validation message is not displayed when entering an invalid value (which is not on the list) and submitting it. Test code: <rich:select id="idSelect" value="#{backingBean.value}" enableManualInput="true"> <f:selectItem itemLabel="Option 1" itemValue="Option 1" /> <f:selectItem itemLabel="Option 2" itemValue="Option 2" /> </rich:select> [1]: https://access.redhat.com/knowledge/docs/en-US/JBoss_Web_Framework_Kit/2/... -- 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

12 years

8
47
0 / 0

[JBoss JIRA] (RF-12254) kitchensink archetype - accessing wrong facelet is held in session and consequently accessing a correct one causes HTTP Status 500

by Juraj Huska (JIRA)

Juraj Huska created RF-12254: -------------------------------- Summary: kitchensink archetype - accessing wrong facelet is held in session and consequently accessing a correct one causes HTTP Status 500 Key: RF-12254 URL: https://issues.jboss.org/browse/RF-12254 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: archetype, mobile Affects Versions: 4.2.2.Final Environment: project generated from kitchensink archetype Reporter: Juraj Huska Priority: Minor When accessing wrong facelet on mobile device and consequently the right application context, then the HTTP Status 500 is returned with error message, which can be viewed in the attached screenshot. It is caused because the {{PageBean}} hold the wrong part of the URL in the session, {code} public void setLocation(String location) { this.location = location; this.page = String.format("/mobile/%s.xhtml", location); } {code} Note that I have tried to change the scope of the PageBean to RequestScoped, but then the list with members what not updated with the new created ones. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

3
13
0 / 0

[JBoss JIRA] (RF-12076) Kitchensink archetype - back button does not back to the correct page state

by Juraj Huska (JIRA)

Juraj Huska created RF-12076: -------------------------------- Summary: Kitchensink archetype - back button does not back to the correct page state Key: RF-12076 URL: https://issues.jboss.org/browse/RF-12076 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: archetype Affects Versions: 4.2.0.Final Reporter: Juraj Huska Priority: Minor When clicking on the url of the freshly created new member (like /rest/members/0) and backing back from the xml viewing, results in removed freshly added member. After refresh, or AJAX update (clicking on accordion panel), the table is with all members again. This happens only for freshly added members. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

3
15
0 / 0

[JBoss JIRA] (RF-12281) rich:tree is iterated multiple times when item is selected

by Alex Vb (JIRA)

Alex Vb created RF-12281: ---------------------------- Summary: rich:tree is iterated multiple times when item is selected Key: RF-12281 URL: https://issues.jboss.org/browse/RF-12281 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: component-tree Affects Versions: 4.2.2.Final Reporter: Alex Vb I have a decently sized tree and I'm using the selectionChangeListener in combination with toggleType="client" selectionType="ajax" render="node" to trigger a selection event on the server. The panelGroup "node" is re-rendered afterwards but it takes 1-2 seconds for each request. After enabling some debug logging I noticed that the entire tree is iterated 4 times for each request. Note a small test-tree exhibiting the same behavior: 2012-05-22 08:39:29.287 DEBUG CustomPhaseListener - Before phase: APPLY_REQUEST_VALUES 2 2012-05-22 08:39:29.287 DEBUG TreeNodeBase - getChildrenKeysIterator(0) 2012-05-22 08:39:29.287 DEBUG TreeNodeBase - getChild(1) 2012-05-22 08:39:29.287 DEBUG TreeNodeBase - getChildrenKeysIterator(1) 2012-05-22 08:39:29.287 DEBUG TreeNodeBase - getChild(2) 2012-05-22 08:39:29.287 DEBUG TreeNodeBase - getChild(2) 2012-05-22 08:39:29.287 DEBUG TreeNodeBase - getChild(2) 2012-05-22 08:39:29.287 DEBUG Bean - selectionChanged() 2012-05-22 08:39:29.287 DEBUG CustomPhaseListener - After phase: APPLY_REQUEST_VALUES 2 2012-05-22 08:39:29.287 DEBUG CustomPhaseListener - Before phase: PROCESS_VALIDATIONS 3 2012-05-22 08:39:29.287 DEBUG TreeNodeBase - getChildrenKeysIterator(0) 2012-05-22 08:39:29.287 DEBUG TreeNodeBase - getChild(1) 2012-05-22 08:39:29.287 DEBUG TreeNodeBase - getChildrenKeysIterator(1) 2012-05-22 08:39:29.287 DEBUG TreeNodeBase - getChild(2) 2012-05-22 08:39:29.302 DEBUG TreeNodeBase - getChild(2) 2012-05-22 08:39:29.302 DEBUG CustomPhaseListener - After phase: PROCESS_VALIDATIONS 3 2012-05-22 08:39:29.302 DEBUG CustomPhaseListener - Before phase: UPDATE_MODEL_VALUES 4 2012-05-22 08:39:29.302 DEBUG TreeNodeBase - getChildrenKeysIterator(0) 2012-05-22 08:39:29.302 DEBUG TreeNodeBase - getChild(1) 2012-05-22 08:39:29.302 DEBUG TreeNodeBase - getChildrenKeysIterator(1) 2012-05-22 08:39:29.302 DEBUG TreeNodeBase - getChild(2) 2012-05-22 08:39:29.302 DEBUG TreeNodeBase - getChild(2) 2012-05-22 08:39:29.302 DEBUG CustomPhaseListener - After phase: UPDATE_MODEL_VALUES 4 2012-05-22 08:39:29.302 DEBUG CustomPhaseListener - Before phase: INVOKE_APPLICATION 5 2012-05-22 08:39:29.302 DEBUG CustomPhaseListener - After phase: INVOKE_APPLICATION 5 2012-05-22 08:39:29.302 DEBUG CustomPhaseListener - Before phase: RENDER_RESPONSE 6 2012-05-22 08:39:29.302 DEBUG TreeNodeBase - getChild(2) 2012-05-22 08:39:29.318 DEBUG TreeNodeBase - getChildrenKeysIterator(0) 2012-05-22 08:39:29.318 DEBUG TreeNodeBase - getChild(1) 2012-05-22 08:39:29.318 DEBUG TreeNodeBase - getChildrenKeysIterator(1) 2012-05-22 08:39:29.318 DEBUG TreeNodeBase - getChild(2) 2012-05-22 08:39:29.318 DEBUG TreeNodeBase - getChild(2) 2012-05-22 08:39:29.318 DEBUG CustomPhaseListener - After phase: RENDER_RESPONSE 6 On the rather large tree each iteration takes 300-500 ms which explains the slow behavior. I have played around with every setting I could find, if selectionType is set to "client" the tree is iterated only once (during the render response phase) but the selection event does not seem to be triggered. If toggleType is set to ajax, only the "expanded" parts of the tree are iterated. I have no idea why the iteration is necessary for all these phases but I "fixed" it in my implementation by recompiling the org.richfaces.component.TreeRange class with an updated method: public boolean shouldIterateChildren() { if (tree.isLeaf()) return false; else { char separatorChar = UINamingContainer.getSeparatorChar(FacesContext.getCurrentInstance()); String clientId = tree.getClientId(); boolean render = false; for (String idToRender : FacesContext.getCurrentInstance().getPartialViewContext().getRenderIds()) { // render the tree if you explicitly mention either the client id (e.g. "menuForm:tree") or the parent component client id (e.g. "menuForm") // note that when clicking on an object in the tree, the following render target is requested: menuForm:tree@selection if (clientId.equals(idToRender) || clientId.matches(idToRender + separatorChar + ".*")) { render = true; break; } } // always render if it's not a postback return render || !FacesContext.getCurrentInstance().isPostback(); } } -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

3
8
0 / 0

[JBoss JIRA] (RF-12438) Tree: Icon-Attribute does not show any effect

by Martin Maier (JIRA)

Martin Maier created RF-12438: --------------------------------- Summary: Tree: Icon-Attribute does not show any effect Key: RF-12438 URL: https://issues.jboss.org/browse/RF-12438 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: component-tree Affects Versions: 4.2.2.Final Environment: Java7, Tomcat7 Reporter: Martin Maier The 'icon' Attribute of rich:treeNode does have any effect. Whatever value you use, always the default icon is displayed. It even shows incorrectly in the Richfaces Showcase (http://showcase.richfaces.org/richfaces/component-sample.jsf?demo=tree&sk...). In the showcase, companies and songs are supposed to have different icons (disc.gif and song.gif). They show as default folder/document icons. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

3
9
0 / 0

[JBoss JIRA] (RF-12445) Autocomplete: wrong output for suggestions with 2 or more words

by Pavol Pitonak (JIRA)

Pavol Pitonak created RF-12445: ---------------------------------- Summary: Autocomplete: wrong output for suggestions with 2 or more words Key: RF-12445 URL: https://issues.jboss.org/browse/RF-12445 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: component-input Affects Versions: 4.3.0.Milestone1 Environment: RichFaces 4.3.0.M1 all browsers Reporter: Pavol Pitonak # open autocomplete sample in Showcase http://showcase.richfaces.org/richfaces/component-sample.jsf?demo=autocom... # type "no" to the third input on the page # select "North Carolina" either using keyboard or using mouse result: * input contains "North Carolina Carolina" * the behavior is probably caused by *selectFirst* attribute because the first two samples work -- 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

12 years

4
10
0 / 0

[JBoss JIRA] (RF-12398) UIDataAdaptor keepSaved method returns true when maximum severity is NOT greater than SEVERITY_ERROR

by Tomasz Kurpios (JIRA)

Tomasz Kurpios created RF-12398: ----------------------------------- Summary: UIDataAdaptor keepSaved method returns true when maximum severity is NOT greater than SEVERITY_ERROR Key: RF-12398 URL: https://issues.jboss.org/browse/RF-12398 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0.0.Final Reporter: Tomasz Kurpios According to the description in [RF-8586] UIDataAdaptor should reset child state when severity is at least ERROR. However it does the opposite - when it is at most ERROR. That's what is checked: {code} FacesMessage.SEVERITY_ERROR.compareTo(sev) >= 0 {code} And that's what should be checked: {code} {code} FacesMessage.SEVERITY_ERROR.compareTo(sev) <= 0 {code} {code} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

3
9
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

richfaces-issues September 2012