September 2013 - richfaces-issues

[JBoss JIRA] (RF-13157) rich:dropDownMenu under rich:accordion cannot work

by David Lee (JIRA)

[ https://issues.jboss.org/browse/RF-13157?page=com.atlassian.jira.plugin.s... ] David Lee commented on RF-13157: -------------------------------- Sorry for reply late -- Been working on other project. After I tried to modfiy the z-index still not working... Seems because the css class: .rf-ac-itm-cnt { border-color: #BED6F8; border-style: solid; border-width: 1px; color: #000000; font-family: Arial,Verdana,sans-serif; font-size: 11px; overflow-x: hidden; overflow-y: auto; padding: 10px; position: relative; } If I take off { overflow-x: hidden; overflow-y: auto; } Then it can works fine. > rich:dropDownMenu under rich:accordion cannot work > -------------------------------------------------- > > Key: RF-13157 > URL: https://issues.jboss.org/browse/RF-13157 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-menu > Affects Versions: 4.3.3 > Environment: Richfaces4.3.3 / CentOS6 / FireFox > Reporter: David Lee > Assignee: Pavol Pitonak > Labels: waiting_on_user > > When I tried to put rich:dropDownMenu under rich:accordion, > the side menu item cannot display on the right hand side. > Please see the image of trouble screen. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (RF-13218) Check existence of src/main/widgets with enforcer plugin

by Lukáš Fryč (JIRA)

[ https://issues.jboss.org/browse/RF-13218?page=com.atlassian.jira.plugin.s... ] Lukáš Fryč reassigned RF-13218: ------------------------------- Assignee: Michal Petrov Hey Michal, could you please create a pull request for this? > Check existence of src/main/widgets with enforcer plugin > -------------------------------------------------------- > > Key: RF-13218 > URL: https://issues.jboss.org/browse/RF-13218 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: build/distribution > Affects Versions: 5.0.0.Alpha1 > Reporter: Lukáš Fryč > Assignee: Michal Petrov > Fix For: 5.0.0.Alpha2 > > > RichFaces 5 may fail when {{src/main/widgets}} aren't checked out properly. > I suggest to use enforcer plugin to check that e.g. {{src/main/widgets/Grunfile.js}} file exists: > http://maven.apache.org/enforcer/enforcer-rules/requireFilesExist.html -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (RF-13082) Change the orderingList component to use the new orderingList widget

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13082?page=com.atlassian.jira.plugin.s... ] Brian Leathem commented on RF-13082: ------------------------------------ I made some compromises (ie. not vertically centering the picklist button column) and this is the style rule needed to set the pick-list size: {code} <style type="text/css"> .pick-list .scrollBox { max-height: 250px; // or height } </style> {code} The above css style results in a scrollbar being added to the source and target lists when the number of elements in the respective lists is sufficiently large. This works well in both the large and small (responsive) views. With this re-factoring, we _could_ expose this value as a widget-option/facelet-attribute. {panel:bgColor=#FFFFCE} *Note:* Setting the height of the .pick-list itself will lead to overlapping content in responsive mode. {panel} > Change the orderingList component to use the new orderingList widget > -------------------------------------------------------------------- > > Key: RF-13082 > URL: https://issues.jboss.org/browse/RF-13082 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-selects > Reporter: Brian Leathem > Assignee: Brian Leathem > Fix For: 5.0.0.Alpha2 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > Attributes to be dropped in the RF5 implementation: > * disabledClass > * headerClass > * itemClass > * selectItemClass > * listHeight > * listWidth > * listMaxHeight > * listMaxWidth > It is felt that the *Class attributes are redundant. Custom component styling can be achieved with the combination of the CSS class specified by the _styleClass_ attribute, along with the relevant stateful CSS class (_disabled_, _header_, _ui-selectee_, ui-selected_). > Similarly the height/width CSS attributes are better set with CSS styles, rather than via facelet attributes. > Additionally, we should consider dropping the onlist* event handlers, as there is considerable overlap with their on* counterparts. For instance, are there really use cases that require differentiating between onmouveover and onlistmouseover? -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (RF-13082) Change the orderingList component to use the new orderingList widget

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13082?page=com.atlassian.jira.plugin.s... ] Brian Leathem commented on RF-13082: ------------------------------------ Using the jQuery _.css_ method to dynamically set css attributes sets the inline-style of an element. This overrides the values in the stylesheet, which poses it's own set of problems when dealing with a responsive layout, as one can no longer rely on the media queries to set an elements height as the size of the viewport changes. Some possible solutions: # Manipulate the CSS stylesheet attributes directly through the DOM. This would be gross. # Dynamically generating and including a CSS stylesheet in the facelet renderer. This does not solve the problem for styling the RichWidget. # Reconsider the current layout approach, optimizing for ease of styling. I will spend some time brainstorming on 3) > Change the orderingList component to use the new orderingList widget > -------------------------------------------------------------------- > > Key: RF-13082 > URL: https://issues.jboss.org/browse/RF-13082 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-selects > Reporter: Brian Leathem > Assignee: Brian Leathem > Fix For: 5.0.0.Alpha2 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > Attributes to be dropped in the RF5 implementation: > * disabledClass > * headerClass > * itemClass > * selectItemClass > * listHeight > * listWidth > * listMaxHeight > * listMaxWidth > It is felt that the *Class attributes are redundant. Custom component styling can be achieved with the combination of the CSS class specified by the _styleClass_ attribute, along with the relevant stateful CSS class (_disabled_, _header_, _ui-selectee_, ui-selected_). > Similarly the height/width CSS attributes are better set with CSS styles, rather than via facelet attributes. > Additionally, we should consider dropping the onlist* event handlers, as there is considerable overlap with their on* counterparts. For instance, are there really use cases that require differentiating between onmouveover and onlistmouseover? -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (RF-13082) Change the orderingList component to use the new orderingList widget

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13082?page=com.atlassian.jira.plugin.s... ] Brian Leathem commented on RF-13082: ------------------------------------ On further experimentation, I believe it would be a good idea to keep the height/width attributes. Because the pickList uses the Bootstrap grid mechanism to provide a responsive widget, one cannot simply set the height of the parent container and expect the nested divs to fit in that height. While achievable in the "desktop" or wide-screen layout, the floating columns quickly spill out of the height constrained parent when the widget is displayed in "mobile" or narrow-screen layout. Instead of setting the height style at the top-level of the component, one has to instead style several internal classes of the widgets (very much an implementation detail). This has been abstracted out using LESS, but I believe that the use case of tailoring the height of an ordering/pick list warrants a more straightforward approach then rebuilding an applications skin everytime the height of an ordering/pick list needs to be adjusted. I will proceed with keeping the height/width attributes for the initial implementation. Th topic of their inclusion can be further discussed as we see how other responsive widgets/components unfold. {panel:title=TL/DR} We should consider only removing component style-related attributes that are replaceable by using the _style_ attribute of the component. (Note: this does not apply to removing the multitude of redundant *Class attributes). {panel} > Change the orderingList component to use the new orderingList widget > -------------------------------------------------------------------- > > Key: RF-13082 > URL: https://issues.jboss.org/browse/RF-13082 > Project: RichFaces > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: component-selects > Reporter: Brian Leathem > Assignee: Brian Leathem > Fix For: 5.0.0.Alpha2 > > Original Estimate: 1 day > Remaining Estimate: 1 day > > Attributes to be dropped in the RF5 implementation: > * disabledClass > * headerClass > * itemClass > * selectItemClass > * listHeight > * listWidth > * listMaxHeight > * listMaxWidth > It is felt that the *Class attributes are redundant. Custom component styling can be achieved with the combination of the CSS class specified by the _styleClass_ attribute, along with the relevant stateful CSS class (_disabled_, _header_, _ui-selectee_, ui-selected_). > Similarly the height/width CSS attributes are better set with CSS styles, rather than via facelet attributes. > Additionally, we should consider dropping the onlist* event handlers, as there is considerable overlap with their on* counterparts. For instance, are there really use cases that require differentiating between onmouveover and onlistmouseover? -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (RF-13216) PoupPanel doesn't disappear when rendered="false" and rerender it.

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13216?page=com.atlassian.jira.plugin.s... ] Brian Leathem commented on RF-13216: ------------------------------------ Quoting from the Richfaces 4 docs: http://docs.jboss.org/richfaces/latest_4_X/Component_Reference/en-US/html... {quote} Placement The <rich:popupPanel> component is usually rendered in front of any other objects on the page. This is achieved by attaching the component to the <body> element of the page, and setting a very high "z-index" (the stack order of the object). This approach is taken because relatively-positioned elements could still overlap the pop-up panel if they exist at higher levels of the DOM hierarchy, even if their z-index is less than the <rich:popupPanel> component. If the <rich:popupPanel> is to participate in submitting child components/behaviors, then a form element must be nested within the <rich:popupPanel>. Alternatively, if no overlapping elements exist, the <rich:popupPanel> component can be reattached to its original DOM element by setting domElementAttachment to either parent or form. {quote} This clearly states that using _domElementAttachment="body"_ is for use cases where the popup does not "participate in submitting child components/behaviors" ie. AJAX. for the described use case: # set _domElementAttachment="form"_ and have both the popup and the calling page in the same form. # If separate forms are preferable, try setting _domElementAttachment="body"_ and using a nested form in the popupPanel. When the popup is closed refresh the page with a full JSF page load, rather than an AJAX update. > PoupPanel doesn't disappear when rendered="false" and rerender it. > ------------------------------------------------------------------ > > Key: RF-13216 > URL: https://issues.jboss.org/browse/RF-13216 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: component-output > Affects Versions: 4.3.3 > Reporter: Takayuki Konishi > Attachments: rf3_3_4-modalpanel.zip, rf4_3_3-popuppanel.zip > > > If you use the richfaces popupPanel in the default domElementAttachment="body" mode it will not disappear under specific conditions. > {code:xml} > <h:body title="page 1"> > <a4j:outputPanel id="myPanel"> > <rich:popupPanel domElementAttachment="body" show="true" rendered="#{test.showPopup}"> > <h:form> > <a4j:commandButton action="#{test.switchPopup()}" value="switch off" render="myPanel"/> > </h:form> > </rich:popupPanel> > <h:form> > <a4j:commandButton action="#{test.switchPopup()}" value="switch on" render="myPanel"/> > </h:form> > </a4j:outputPanel> > </h:body> > {code} > In Richfaces 3.3.x, on the other hand, there was a component cleanup system ({{memory.js _cleanComponentNodes}}) which was responsible to remove components after ajax calls if the component was removed from the current view. > Therefore the above example (revert {{popupPanel}} to {{modalPanel}}) works in RF3.3.4.Final. > Note: > In case {{domElementAttachment="parent"}}, it will show [the other JSF2 bug|https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-790] where the view state was lost, therefore you must click the action button twice to really call the function. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (RF-13218) Check existence of src/main/widgets with enforcer plugin

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13218?page=com.atlassian.jira.plugin.s... ] Brian Leathem updated RF-13218: ------------------------------- Fix Version/s: 5.0.0.Alpha2 > Check existence of src/main/widgets with enforcer plugin > -------------------------------------------------------- > > Key: RF-13218 > URL: https://issues.jboss.org/browse/RF-13218 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: build/distribution > Affects Versions: 5.0.0.Alpha1 > Reporter: Lukáš Fryč > Fix For: 5.0.0.Alpha2 > > > RichFaces 5 may fail when {{src/main/widgets}} aren't checked out properly. > I suggest to use enforcer plugin to check that e.g. {{src/main/widgets/Grunfile.js}} file exists: > http://maven.apache.org/enforcer/enforcer-rules/requireFilesExist.html -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (RF-13220) Quickstart - Remove references to AS 7.1 in the RichFaces quickstarts

by Sande Gilda (JIRA)

[ https://issues.jboss.org/browse/RF-13220?page=com.atlassian.jira.plugin.s... ] Sande Gilda moved JDF-508 to RF-13220: -------------------------------------- Project: RichFaces (was: JBoss Developer Framework) Key: RF-13220 (was: JDF-508) Issue Type: Bug (was: Feature Request) Component/s: examples (was: quickstarts) Security: Public > Quickstart - Remove references to AS 7.1 in the RichFaces quickstarts > --------------------------------------------------------------------- > > Key: RF-13220 > URL: https://issues.jboss.org/browse/RF-13220 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: examples > Reporter: Sande Gilda > Assignee: Sande Gilda > > The readme files provide instruction on how to run quickstarts on both AS 7.1 and EAP 6. Quickstarts now target EAP 6.1, so we need to remove references to AS 7.1. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (RF-13220) Quickstart - Remove references to AS 7.1 in the RichFaces quickstarts

by Sande Gilda (JIRA)

[ https://issues.jboss.org/browse/RF-13220?page=com.atlassian.jira.plugin.s... ] Sande Gilda updated RF-13220: ----------------------------- Assignee: Vineet Reynolds (was: Sande Gilda) > Quickstart - Remove references to AS 7.1 in the RichFaces quickstarts > --------------------------------------------------------------------- > > Key: RF-13220 > URL: https://issues.jboss.org/browse/RF-13220 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: examples > Reporter: Sande Gilda > Assignee: Vineet Reynolds > > The readme files provide instruction on how to run quickstarts on both AS 7.1 and EAP 6. Quickstarts now target EAP 6.1, so we need to remove references to AS 7.1. -- 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, 7 months

1
0
0 / 0

[JBoss JIRA] (RF-13168) 3rd party JSF component disappears on RichFaces ajax refresh

by Brian Leathem (JIRA)

[ https://issues.jboss.org/browse/RF-13168?page=com.atlassian.jira.plugin.s... ] Brian Leathem updated RF-13168: ------------------------------- Original Estimate: 1 hour Remaining Estimate: 1 hour > 3rd party JSF component disappears on RichFaces ajax refresh > ------------------------------------------------------------ > > Key: RF-13168 > URL: https://issues.jboss.org/browse/RF-13168 > Project: RichFaces > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: compatibility, component-a4j-core > Reporter: Frank Langelage > Assignee: Brian Leathem > Labels: interop, jsf22 > Fix For: 4.3.5, 5.0.0.Alpha3 > > Attachments: install-mojarra-2.1.19.cli, Jira-WFLY-UT.tar, xaa, xab, xac > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > On some of my pages I'm using richfaces a4j:poll to refresh components regularly. The components refreshed is an openfaces datatable. > This does not work with WildFly build from current sources. > Same code works with JBoss AS 7.20. So problem is not related to richfaces or openfaces for me. Probably related to replacement of jboss-web with undertow. > I'll attach a small project showing the problem. > The mojarra datatable works fine, is refreshed every 10 seconds. > The openfaces datatable below disappears on first refresh. -- 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, 7 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 September 2013