[JBoss JIRA] (RF-13164) Skinning of standard inputs not consistent
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13164?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13164:
-------------------------------
Fix Version/s: 5.0.0.Alpha2
> Skinning of standard inputs not consistent
> ------------------------------------------
>
> Key: RF-13164
> URL: https://issues.jboss.org/browse/RF-13164
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: skinning
> Affects Versions: 5.0.0.Alpha2
> Reporter: Pavol Pitonak
> Fix For: 5.0.0.Alpha2
>
>
> In 5.0.0-SNAPSHOT standard JSF inputs (such as h:inputText) are skinned by RichFaces or by Bootstrap depending on which components are used on page.
> When a new component (e.g. autocomplete) is used, it includes Bootstrap CSS file which overrides RichFaces skinning.
> Bootstrap CSS file should be probably included for each component.
--
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
[JBoss JIRA] (RF-12865) A4j:commandButton fail to render/update other components with MyFaces
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12865?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-12865:
------------------------------------
[~dageisz] we'll consider a backport of the fix to a RichFaces 4.3.x release if it's reasonable to do so.
> A4j:commandButton fail to render/update other components with MyFaces
> ---------------------------------------------------------------------
>
> Key: RF-12865
> URL: https://issues.jboss.org/browse/RF-12865
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: third-party
> Affects Versions: 4.3.1
> Environment: weblogic 10.3.4, Myfaces 2.1.10, Richfaces 4.3.1, OmniFaces1.3
> Reporter: blam lam
> Labels: jsf
> Fix For: 5.0.0.Alpha2
>
>
> After submit from a a4j:commandButton, it fail to re-render / update other component on the page.
> This problem only appear in MyFaces. It does not happens in Mojarra.
--
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
[JBoss JIRA] (RF-13162) Add support for the default-behavior faces-config property-extension to the CDK @Attribute annotation
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13162?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-13162:
------------------------------------
There is some confusion about the overlap of the _<cdk:event-name default="true">_ element, the _<default-behavior>_, and the _[ClientBehaviorHolder.html#getDefaultEventName()|https://github.com/rich....
Some insight can be gained by comparing the CDK property definition above (from this issue's description) with this one for the [command-button-props.xml|https://github.com/jboss/mojarra/blob/2.1.21-jbo...] configuration from the Mojarra project:
{code}
<property>
<description>
Javascript code executed when a pointer button is
clicked over this element.
</description>
<display-name>Button Click Script</display-name>
<icon></icon>
<property-name>onclick</property-name>
<property-class>java.lang.String</property-class>
<property-extension>
<pass-through>false</pass-through>
<behavior/>
<behavior>action</behavior>
<default-behavior>true</default-behavior>
</property-extension>
</property>
{code}
Here the _<default-behavior>true<default-behavior>_ element makes sense, as it is accompanied by the _<behavior>action</behavior>_ element identifying which behavior is the default. Contrast this with the CDK configuration where the _<default-behavior>_ element does not have an accompanying _<behavior>_ element. What purpose does the _<default-behavior>true</default-behavior>_ element serve in the CDK faces-config snippet?
In a conversation with [~edburns] in IRC, he suggested that the _<default-behavior>_ faces-config.xml property configuration is present for consumption by tooling.
So it would seem that a better resolution of this issue would be for the CDK _@Attribute_ annotation to use the existing [events attribute + default|https://github.com/richfaces/richfaces-cdk/blob/master/annotation...] property to render the appropriate _<behavior>_ and _<default-behavior>_ elements.
> Add support for the default-behavior faces-config property-extension to the CDK @Attribute annotation
> -----------------------------------------------------------------------------------------------------
>
> Key: RF-13162
> URL: https://issues.jboss.org/browse/RF-13162
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: cdk
> Reporter: Brian Leathem
> Assignee: Brian Leathem
> Fix For: cdk-4.5.0.Alpha2
>
>
> Consider the xml component property definition:
> {code:title=From command-button-props.xml}
> <property>
> <description>
> Javascript code executed when a pointer button is clicked over this element.
> </description>
> <display-name>Button Click Script</display-name>
> <icon />
> <property-name>onclick</property-name>
> <property-class>java.lang.String</property-class>
> <property-extension>
> <cdk:pass-through>false</cdk:pass-through>
> <cdk:event-name default="true">click</cdk:event-name>
> <cdk:event-name>action</cdk:event-name>
> <default-behavior>true</default-behavior>
> </property-extension>
> </property>
> {code}
> There is currently no way to define this using the CDK @Attribute annotation - the _<default-behavior>_ annotation property is absent.
> To resolve this issue (blocking RF-12952) we need to add support for specifying the _default-behavior_ to the @Attribute annotation.
--
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
[JBoss JIRA] (RF-13154) a4j:push fails with CNFE for org.apache.coyote.http11.upgrade.UpgradeInbound on latest EAP 6
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13154?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-13154:
------------------------------------
The pull request was merged. I spoke with [~jfarcand] on IRC and he has agreed to do a 1.0.17 release of atmosphere this week that incorporates this patch.
[~ppitonak] would you please run the RichFaces Push tests against a build of RichFaces from the release/4.3.4 branch to make sure Atmosphere 1.0.17-SNAPSHOT does not introduce any regressions?
> a4j:push fails with CNFE for org.apache.coyote.http11.upgrade.UpgradeInbound on latest EAP 6
> --------------------------------------------------------------------------------------------
>
> Key: RF-13154
> URL: https://issues.jboss.org/browse/RF-13154
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 4.3.3
> Environment: EAP 6.1.1.ER7
> Reporter: Ken Finnigan
> Fix For: 4.3.4
>
>
> When accessing a4j:push example in showcase on EAP 6.1.1.ER7 the network tab of the developer console in Chrome shows failed network attempts for richfaces push and the following exception in the server logs:
> {code}
> 15:21:29,295 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/showcase].[AutoRegisteredPushServlet]] (http-/127.0.0.1:8080-2) JBWEB000236: Servlet.service() for servlet AutoRegisteredPushServlet threw exception: java.lang.ClassNotFoundException: org.apache.coyote.http11.upgrade.UpgradeInbound from [Module "deployment.richfaces-showcase-4.3.3.Final-jbas71.war:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:196) [jboss-modules.jar:1.2.2.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:444) [jboss-modules.jar:1.2.2.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:432) [jboss-modules.jar:1.2.2.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:374) [jboss-modules.jar:1.2.2.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:119) [jboss-modules.jar:1.2.2.Final-redhat-1]
> at org.atmosphere.container.Tomcat7AsyncSupportWithWebSocket.service(Tomcat7AsyncSupportWithWebSocket.java:59) [atmosphere-runtime-1.0.10.jar:1.0.10]
> at org.atmosphere.cpr.AtmosphereFramework.doCometSupport(AtmosphereFramework.java:1370) [atmosphere-runtime-1.0.10.jar:1.0.10]
> at org.atmosphere.cpr.AtmosphereServlet.doPost(AtmosphereServlet.java:293) [atmosphere-runtime-1.0.10.jar:1.0.10]
> at org.atmosphere.cpr.AtmosphereServlet.doGet(AtmosphereServlet.java:279) [atmosphere-runtime-1.0.10.jar:1.0.10]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:734) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-1.jar:1.0.2.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at org.ocpsoft.rewrite.servlet.RewriteFilter.doFilter(RewriteFilter.java:172) [rewrite-servlet-1.0.4.Final.jar:1.0.4.Final]
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
> at org.jboss.as.jpa.interceptor.WebNonTxEmCloserValve.invoke(WebNonTxEmCloserValve.java:50) [jboss-as-jpa-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.2.1.Final-redhat-10.jar:7.2.1.Final-redhat-10]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:145) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:336) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:856) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:920) [jbossweb-7.2.2.Final-redhat-1.jar:7.2.2.Final-redhat-1]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> {code}
> Running the exact same showcase example war on EAP 6.1.0.GA works fine.
--
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
[JBoss JIRA] (RF-13095) extendedDataTable tableState setter not called on column resize/reorder
by Steven W. (JIRA)
[ https://issues.jboss.org/browse/RF-13095?page=com.atlassian.jira.plugin.s... ]
Steven W. commented on RF-13095:
--------------------------------
Hi - under the 5.0 Alpha release I am getting the following null pointer exception using the following prepared table state:
{"columnsVisibility":{"col0":"1","col1":"1","col2":"1","col3":"1","col4":"1","col5":"1","col6":"1","col7":"1","col8":"1","col9":"1"},"columnsSizeState":{"col0":"0","col1":"250","col2":"110","col3":"100","col4":"94","col5":"250","col6":"200","col7":"120","col8":"228","col9":"100"},"columnsWidthState":{"col0":"0px","col1":"250px","col2":"110px","col3":"100px","col4":"94px","col5":"250px","col6":"200px","col7":"120px","col8":"228px","col9":"100px"},"columnsOrder":["col0","col1","col2","col3","col4","col5","col6","col7","col8","col9"],"columnsOrderState":["col0","col1","col2","col3","col4","col5","col6","col7","col8","col9"],"columnsSortState":{"col0":"descending","col1":"descending","col2":"descending","col3":"descending","col4":"descending","col5":"descending","col6":"descending","col7":"descending","col8":"descending","col9":"descending"}}
2013-09-02 12:52:51,046 ERROR [org.jboss.seam.exception.Exceptions] - handled and logged exception
javax.servlet.ServletException
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:606)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:374)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:83)
at org.jboss.seam.web.LoggingFilter.doFilter(LoggingFilter.java:60)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.IdentityFilter.doFilter(IdentityFilter.java:40)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.MultipartFilter.doFilter(MultipartFilter.java:90)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.ExceptionFilter.doFilter(ExceptionFilter.java:64)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.web.RedirectFilter.doFilter(RedirectFilter.java:45)
at org.jboss.seam.servlet.SeamFilter$FilterChainImpl.doFilter(SeamFilter.java:69)
at org.jboss.seam.servlet.SeamFilter.doFilter(SeamFilter.java:158)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1008)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.lang.NullPointerException
at org.richfaces.ui.iteration.extendedDataTable.ExtendedDataTableRenderer.encodeHeaderOrFooterCell(ExtendedDataTableRenderer.java:259)
at org.richfaces.ui.iteration.extendedDataTable.ExtendedDataTableRenderer.encodeHeaderOrFooter(ExtendedDataTableRenderer.java:374)
at org.richfaces.ui.iteration.extendedDataTable.ExtendedDataTableRenderer.encodeHeader(ExtendedDataTableRenderer.java:492)
at org.richfaces.ui.iteration.extendedDataTable.ExtendedDataTableRenderer.doEncodeChildren(ExtendedDataTableRenderer.java:750)
at org.richfaces.renderkit.RendererBase.encodeChildren(RendererBase.java:158)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:847)
at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeRecursive(HtmlBasicRenderer.java:304)
at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeRecursive(HtmlBasicRenderer.java:309)
at com.sun.faces.renderkit.html_basic.GroupRenderer.encodeChildren(GroupRenderer.java:105)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:847)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1819)
at javax.faces.render.Renderer.encodeChildren(Renderer.java:168)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:847)
at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeRecursive(HtmlBasicRenderer.java:304)
at com.sun.faces.renderkit.html_basic.GroupRenderer.encodeChildren(GroupRenderer.java:105)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:847)
at com.sun.faces.renderkit.html_basic.HtmlBasicRenderer.encodeRecursive(HtmlBasicRenderer.java:304)
at com.sun.faces.renderkit.html_basic.GridRenderer.renderRow(GridRenderer.java:185)
at com.sun.faces.renderkit.html_basic.GridRenderer.encodeChildren(GridRenderer.java:129)
at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:847)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1819)
at javax.faces.component.UIComponent.encodeAll(UIComponent.java:1822)
at com.sun.faces.application.view.FaceletViewHandlingStrategy.renderView(FaceletViewHandlingStrategy.java:447)
at com.sun.faces.application.view.MultiViewHandler.renderView(MultiViewHandler.java:125)
at org.jboss.seam.jsf.SeamViewHandler.renderView(SeamViewHandler.java:188)
at javax.faces.application.ViewHandlerWrapper.renderView(ViewHandlerWrapper.java:286)
at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:120)
at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:101)
at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:139)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:594)
... 33 more
> extendedDataTable tableState setter not called on column resize/reorder
> -----------------------------------------------------------------------
>
> Key: RF-13095
> URL: https://issues.jboss.org/browse/RF-13095
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-tables
> Affects Versions: 4.3.2
> Environment: GlassFish 3.1.2.2 with Mojarra 2.1.23, tested on Firefox 22 and Chrome 28.
> Reporter: Salvo Isaja
> Assignee: Brian Leathem
> Original Estimate: 1 hour
> Remaining Estimate: 1 hour
>
> Not sure if this qualifies as a bug or a feature request.
> I have an extendedDataTable with the tableState attribute bound to a String property of a backing bean (tried both a request scoped bean on a transient view and a session scoped bean on a stateful view).
> When resizing or reordering columns, an Ajax request is posted to the server, and I correctly see the new column layouts in the request, but the setter of the tableState property in the backing bean is not called. If I execute @form on a a4j:commandLink or commandButton, it is called instead.
> Thanks
--
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
[JBoss JIRA] (RF-13164) Skinning of standard inputs not consistent
by Pavol Pitonak (JIRA)
Pavol Pitonak created RF-13164:
----------------------------------
Summary: Skinning of standard inputs not consistent
Key: RF-13164
URL: https://issues.jboss.org/browse/RF-13164
Project: RichFaces
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: skinning
Affects Versions: 5.0.0.Alpha2
Reporter: Pavol Pitonak
In 5.0.0-SNAPSHOT standard JSF inputs (such as h:inputText) are skinned by RichFaces or by Bootstrap depending on which components are used on page.
When a new component (e.g. autocomplete) is used, it includes Bootstrap CSS file which overrides RichFaces skinning.
Bootstrap CSS file should be probably included for each component.
--
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
[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:
--------------------------------
uh...ok, so I'll need to write my own css to solve the rich:dropDownMenu inside.
The other issue is about the rich:accordion height.
I found the height of my "selected" rich:accordionItem will be 20px smaller than others,
that cause the content of them cannot display completely.
Is this is a bug?
I'm using dynamic rich:accordionItem ... is any more settings I'll need to add?
Thanks.
Following is my code:
<rich:accordion switchType="client" activeItem="#{componentNavigator.currentComponent.group}"
itemContentClass="main_menu_context" >
<c:forEach items="#{customizeMainMenu.menuBarItemsList}" var="panels">
<ui:include src="/tool/menuItems.xhtml" />
</c:forEach>
</rich:accordion>
Inside menuItems.xhtml:
<ui:composition xmlns="http://www.w3.org/1999/xhtml"
xmlns:ui="http://java.sun.com/jsf/facelets"
xmlns:h="http://java.sun.com/jsf/html"
xmlns:f="http://java.sun.com/jsf/core"
xmlns:a4j="http://richfaces.org/a4j"
xmlns:s="http://jboss.org/schema/seam/taglib"
xmlns:rich="http://richfaces.org/rich">
<rich:accordionItem title="#{id}" id="#{id}" name="#{id}"
rendered="#{componentNavigator.isPanelBarAllowed.get(renderPath)}">
<f:facet name="header">
...
</f:facet>
...
</rich:accordionItem>
</ui:composition>
> 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