June 2012 - richfaces-issues - Jboss List Archives

[JBoss JIRA] (RF-12241) rich:column sortBy attribute expects a value expression not a constant

by Craig Ringer (JIRA)

Craig Ringer created RF-12241: --------------------------------- Summary: rich:column sortBy attribute expects a value expression not a constant Key: RF-12241 URL: https://issues.jboss.org/browse/RF-12241 Project: RichFaces Issue Type: Bug Security Level: Public (Everyone can see) Components: component-tables Affects Versions: 4.2.1.Final Environment: JBoss AS 7.1.1.Final craig@wallace:~/projects/booksys/nymm$ uname -a Linux wallace 3.2.0-24-generic-pae #37-Ubuntu SMP Wed Apr 25 10:47:59 UTC 2012 i686 i686 i386 GNU/Linux craig@wallace:~/projects/booksys/nymm$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 12.04 LTS Release: 12.04 Codename: precise craig@wallace:~/projects/booksys/nymm$ java -version java version "1.7.0" Java(TM) SE Runtime Environment (build 1.7.0-b147) Java HotSpot(TM) Server VM (build 21.0-b17, mixed mode) Reporter: Craig Ringer Priority: Minor Using a rich:dataTable with a rich:column that has a sortOrder and sortBy set, backed by an ExtendedDataModel implementing Arrangeable, no ArrangeableState is set on the underlying model unless `sortBy' is an EL value expression. If `sortBy' is a constant, the arrangeable state remains null. The ValueExpression may point to a bean accessor that returns the exact same string value as was provided as a constant. The value expression version will work, the constant one won't. Even if the value expression is simply an EL expression for a string literal it works. This works: sortBy="#{'code'}" this silently fails as if sortBy= wasn't present: sortBy="code" ... and that looks like a bug to me. For example, take the toy code: {code} <h:form id="customerForm"> <rich:dataTable id="customerTable" var="customer" value="#{customers.model}" rows="50">   <rich:column sortBy="${customers.sortBy}" sortOrder="#{customers.codeSortOrder}" id="code"> <f:facet name="header"> <h:outputText value="Customer Code"/> <h:outputText value="Sorting: #{customers.codeSortOrder}"/> </f:facet> <h:outputText value="#{customer.code}" /> </rich:column> <rich:column id="name"> <f:facet name="header"> <h:outputText value="Customer Name"/> </f:facet> <h:outputText value="#{customer.name}" /> </rich:column> </rich:dataTable> <rich:dataScroller for="customerTable" /> </h:form> {code} where "customers" is: {code} @Named @RequestScoped public class Customers { // "CustomerDataModel" is a JPADataModel<Customer> as per // http://showcase.richfaces.org/richfaces/component-sample.jsf?demo=dataTab... // and the nature of the "Customer" entity is irrelevant beyond the fact that it has "name" and "code" properties. @Inject private CustomerDataModel dataModel; private SortOrder codeSortOrder = SortOrder.ascending, nameSortOrder = SortOrder.ascending; public CustomerDataModel getModel() { return dataModel; } public String getSortBy() { return "code"; } // blah blah accessors for members omitted for brevity since most IDE-generate them anyway // Maybe Java will get real properties one day.... } {code} Clearly, #{customers.sortBy} evaluates to the string "code". Yet if we write: sortBy="code" no ArrangeableState is set on the backing Arrangeable ExtendedDataModel. Writing the effectively identical: sortBy="#{customers.sortBy}" works, as does: sortBy="#{'code'}" Try it out on the RichFaces showcase example. I suspect the reason this didn't get caught was that the showcase uses an include to repeat the columns, so it's using a value expression to indirect the constant. http://showcase.richfaces.org/richfaces/component-sample.jsf?demo=dataTab... -- 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 months

4
10
0 / 0

[JBoss JIRA] (RF-12328) Add a rich:jquery function in EL to call a jQuery object from a JSF id

by Paul Dijou (JIRA)

12 years, 4 months

3
5
0 / 0

[JBoss JIRA] (RF-12347) popupPanel shrinks while moving on zoomed page

by Dun Pierrafeu (JIRA)

12 years, 4 months

3
2
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, 4 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, 4 months

2
1
0 / 0

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

by Nitesh S (JIRA)

12 years, 4 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, 4 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, 4 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, 4 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, 4 months

2
7
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

richfaces-issues June 2012