August 2012 - richfaces-issues - Jboss List Archives

[JBoss JIRA] (RF-12352) rich:fileUpload does not work properly with Mojarra 2.1.7 when FacesContext.isPostback() is executed before FacesContext.getPartialViewContext()

by Tomasz Kurpios (JIRA)

Tomasz Kurpios created RF-12352: ----------------------------------- Summary: rich:fileUpload does not work properly with Mojarra 2.1.7 when FacesContext.isPostback() is executed before FacesContext.getPartialViewContext() Key: RF-12352 URL: https://issues.jboss.org/browse/RF-12352 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: component-input Affects Versions: 4.0.0.Final Environment: Mojarra 2.1.7, Jetty or JBoss 5.1 Reporter: Tomasz Kurpios In Mojarra 2.1.7 the value of first invocation of FacesContextImpl.isPostback() is cached as a request attribute. It checks for the existence of javax.faces.ViewState parameter. If we are processing MultipartRequest and FacesContextImpl.isPostback() is executed before FacesContextImpl.getPartialViewContext(), FileUploadPartialViewContextFactory hasn't had yet chance to parse this MultipartRequest's parameters, so FacesContextImpl.isPostback() returns (and caches) false. Therefore no processing (decodes, validations, updates) happens and as a consequence properly registered FileUploadListener is not executed. The only reason why it normally works is because completely unrelated method, com.sun.faces.context.ExceptionHandlerFactoryImpl.getExceptionHandler(), *happens to* call FacesContext.getPartialViewContext() and this happens during creation of FacesContext instance. In my environment, I used my custom ExceptionHandlerFactory (registered in faces-config.xml) which did not call FacesContext.getPartialViewContext() and the problem appeared, because FacesContext.isPostback() was called first. This means that currently FileUploadPartialViewContextFactory is very tightly coupled to FacesContextImpl, which in my opinion should be fixed. -- 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 months

2
1
0 / 0

[JBoss JIRA] (RF-11976) Showcase: BaseDescriptor is using com.sun.faces.ELUtils

by Lukáš Fryč (JIRA)

Lukáš Fryč created RF-11976: ------------------------------- Summary: Showcase: BaseDescriptor is using com.sun.faces.ELUtils Key: RF-11976 URL: https://issues.jboss.org/browse/RF-11976 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: showcase Affects Versions: 4.2.0.CR1 Reporter: Lukáš Fryč Priority: Minor ELUtils are not on the classpath, when using MyFaces. {{com.sun.faces.el.ELUtils}} should be replaced with {{org.richfaces.el.util.ELUtils}}. -- 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 months

4
7
0 / 0

[JBoss JIRA] (RF-12333) "oncomplete" (seems like along with "onbeforedomupdate", "data") doesn't work when "@all" keyword specified in "render" attribute

by Alexander Kiselyov (JIRA)

12 years, 3 months

2
1
0 / 0

[JBoss JIRA] (RF-12329) Richfaces rendering fails on Arabic Windows Environment

by Nitesh S (JIRA)

12 years, 3 months

2
2
0 / 0

[JBoss JIRA] (RF-12323) rich:select does not re-render label text when PROCESS_VALIDATIONS is skipped

by Lutz Ulrich (JIRA)

12 years, 3 months

2
3
0 / 0

[JBoss JIRA] (RF-11950) rich:findComponent does not retrieve the component

by Jean ANDRE (JIRA)

Jean ANDRE created RF-11950: ------------------------------- Summary: rich:findComponent does not retrieve the component Key: RF-11950 URL: https://issues.jboss.org/browse/RF-11950 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: base functionality Affects Versions: 4.1.0.Final Environment: Websphere 8 - RAD 8 - JSF Mojorra 2.1.4 - Spring 3.0.6 Final - Firefox 10.0 - Windows 7 (6.1 sp1) Reporter: Jean ANDRE The rich:findComponent does not retrieve the component - What we want to achieve is to send .click() event on a command button. We got different errors depending the tests we made such as syntax error. The involved code: ------------------    <a4j:commandButton id="#{tab.id}-rcd-cancelCreateCmd" value="#{msg['common.command.cancel']}" onclick="#{rich:findComponent('#{activity.id}-closeCmd')}.click();;return false;" render="#{tab.id}-tabsClient" immediate="true" /> The error we got: ---------------- syntax error - [Stopper sur une erreur] - jsf.js.jsf?ln=javax.faces (ligne 1) .click();return false; The corresponding view source: ------------------------------ <input type="submit" value="Cancel" onclick="jsf.util.chain(this,event,".click();return false;","RichFaces.ajax(\"tabbedForm:TAB_CLIENT\\u002D1\\u002Drcd\\u002DcancelCreateCmd\",event,{\"incId\":\"1\"} )");return false;" name="tabbedForm:TAB_CLIENT-1-rcd-cancelCreateCmd" id="tabbedForm:TAB_CLIENT-1-rcd-cancelCreateCmd"> The generated javaScript under firebug: -------------------------------------- function onclick(event) { jsf.util.chain(this, event, ".click();return false;", "RichFaces.ajax(\"tabbedForm:TAB_CLIENT\\u002D1\\u002Drcd\\u002DcancelCreateCmd\",event,{\"incId\":\"1\"} )"); return false; } If we hard code the Id instead of the calculated one we got following error: uncaught exception: Syntax error, unrecognized expression: TAB_CLIENT-1-TAB_RCD-closeCmd Line 0 The generated javaScript under firebug: -------------------------------------- function anonymous(event) { rich: findComponent("TAB_CLIENT-1-TAB_RCD-closeCmd").click(); return false; } If we use directly jQuery:    <a4j:commandButton id="#{tab.id}-rcd-cancelCreateCmd" value="#{msg['common.command.cancel']}" onclick="$('##{activity.id}-closeCmd').click();return false;" render="desktopTabPanel" immediate="true" /> missing ; before statement http://localhost:12000/crm/javax.faces.resource/jsf.js.jsf?ln=javax.faces Line 1 If we hardcode an existing static Id, we got the error as shown the screen capture: function onclick(event) { jsf.util.chain(this, event, "org.richfaces.component.UICommandButton(a)39de2ca.click();", "RichFaces.ajax(\"tabbedForm:TAB_CLIENT\\u002D1\\u002Drcd\\u002DcancelCreateCmd\",event,{\"incId\":\"1\"} )"); return false; } <a4j:commandButton id="#{tab.id}-rcd-cancelCreateCmd" value="#{msg['common.command.cancel']}" onclick="#{rich:findComponent('qsearchClient')}.click();" render="#{tab.id}-tabsClient" immediate="true" />  -- 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 months

5
19
0 / 0

[JBoss JIRA] (RF-12176) Upgrade to Atmosphere 0.9.x

by Lukáš Fryč (JIRA)

Lukáš Fryč created RF-12176: ------------------------------- Summary: Upgrade to Atmosphere 0.9.x Key: RF-12176 URL: https://issues.jboss.org/browse/RF-12176 Project: RichFaces Issue Type: Component Upgrade Security Level: Public (Everyone can see) Components: component-a4j-core Affects Versions: 4.2.1.Final Reporter: Lukáš Fryč We need to check first how fluent the upgrade is, but as you can see from this discussion [1], the release contains fixes for RF-11940 (which has been worked around locally) [1] https://groups.google.com/forum/?fromgroups#!topic/atmosphere-framework/h... -- 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 months

4
14
0 / 0

[JBoss JIRA] (RF-12235) Do not overwrite encodeBegin/encodeEnd when extending RendererBase

by Lukáš Fryč (JIRA)

Lukáš Fryč created RF-12235: ------------------------------- Summary: Do not overwrite encodeBegin/encodeEnd when extending RendererBase Key: RF-12235 URL: https://issues.jboss.org/browse/RF-12235 Project: RichFaces Issue Type: Enhancement Security Level: Public (Everyone can see) Components: cdk Affects Versions: 4.2.1.Final Reporter: Lukáš Fryč {{cc:implementation}} (resp. {{cdk:body}}) generates {{encodeEnd(...)}} (resp. {{encodeBegin()}} method of renderer. It overrides the implementation in predecessors of the renderer like [{{RendererBase}}|https://github.com/richfaces/components/blob/develop/common/ui/src/main/java/org/richfaces/renderkit/RendererBase.java]. We can just generate {{doEncodeEnd}} and {{doEncodeBegin}} methods instead of {{decodeEnd}} {{encodeEnd}}, which will allow to do not override methods like {{preEncodeEnd}} which allows to write generic implementation. There could be detection in place which would detect if predecessor is {{RendererBase}}. {quote} 4:55:05 <paul_dijou> I was thinking about having hooks in the renderer 14:55:25 <paul_dijou> Right now, when you use a template.xhtml, it will override encodeBegin and encodeEnd 14:55:32 <bleathem> https://github.com/richfaces/components/blob/develop/common/ui/src/main/j... 14:55:39 <bleathem> has the hooks doDecode and doEncode 14:55:51 <bleathem> so you can still use the template 14:56:17 <bleathem> and hook into the decoding/encoding 14:56:17 <paul_dijou> Oh good 14:56:39 <paul_dijou> Hmmm 14:56:50 <bleathem> ... if we keep this up, I'll just copy and paste the IRC minutes into the wiki, and we'll have the whole thing documented ;) 14:56:51 <paul_dijou> But if the template override encodeEnd 14:57:00 <paul_dijou> Who will call doEncodeEnd ? 14:57:30 <paul_dijou> +1 14:57:42 <gastaldi> sorry guys 14:57:50 <lfryc> hmm, as Paul says, CDK generates encodeEnd 14:57:51 <bleathem> hmm, does the template generate encodeEnd, or doEndoceEnd? 14:57:57 <paul_dijou> encodeEnd 14:58:02 <bleathem> ah 14:58:11 <bleathem> then we lose the encode hooks 14:58:12 <lfryc> https://gist.github.com/2568559 14:58:19 <bleathem> (we still have the decode hooks) 14:58:37 <paul_dijou> And btw, if no cdk:body in the template 14:58:40 <lfryc> if you don't overwrite cdk:body :-) 14:58:44 <paul_dijou> It will not write encodeStart at all 14:58:53 <paul_dijou> So parent will still write it's encodeStart 14:58:58 <paul_dijou> But no longuer encodeEnd 14:59:04 <lfryc> we could let CDK behave more smart... 14:59:11 <paul_dijou> That was the problem that lfryc solved about icons 14:59:12 <lfryc> it could check the renderer base 14:59:21 <lfryc> and detect if it is RendererBase class 14:59:30 <lfryc> then it would use doDecode, doEncode instead 14:59:52 <bleathem> or, just call out to doDecode, doEncode in it's generated methods 15:00:12 <lfryc> then you couldn't live without RendererBase from RichFaces 15:00:27 <lfryc> I'm having concerns about backward compatibility 15:00:30 <bleathem> well you could, in the same way you could live without CDK templates {quote} -- 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 months

2
7
0 / 0

[JBoss JIRA] (RF-12307) rich calendar is flickering inside simple toggle panel

by Maitri Parekh (JIRA)

Maitri Parekh created RF-12307: ---------------------------------- Summary: rich calendar is flickering inside simple toggle panel Key: RF-12307 URL: https://issues.jboss.org/browse/RF-12307 Project: RichFaces Issue Type: Quality Risk Security Level: Public (Everyone can see) Reporter: Maitri Parekh Controls cause flickering in rich calendar when it is placed inside toggle panel or tab panel. -- 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 months

2
1
0 / 0

[JBoss JIRA] (RF-12301) rich:validator and rich:ajax inside the same input element

by Jan Papousek (JIRA)

Jan Papousek created RF-12301: --------------------------------- Summary: rich:validator and rich:ajax inside the same input element Key: RF-12301 URL: https://issues.jboss.org/browse/RF-12301 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: component-a4j-core, component-input, component-validators Affects Versions: 4.2.2.Final Reporter: Jan Papousek This issue affects the following input components: - rich:autocomplete - rich:calendar - rich:inplaceInput - rich:inplaceInput - rich:select When the rich:validator and rich:ajax is placed inside the same input element, the order is important. The following code doesn't update update output area: {code} <rich:inplaceInput id="input" value="..."> <rich:validator /> <a4j:ajax event="change" render="output" /> </rich:inplaceInput> <rich:message id="message" for="input"/> <h:outputText id="output" value="..." /> {code} The following code works correctly: {code} <rich:inplaceInput id="input" value="..."> <a4j:ajax event="change" render="output" /> <rich:validator /> </rich:inplaceInput> <rich:message id="message" for="input"/> <h:outputText id="output" value="..." /> {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 months

2
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

richfaces-issues August 2012