[
https://issues.jboss.org/browse/RF-12241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Craig Ringer updated RF-12241:
------------------------------
Description:
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:
{noformat}
sortBy="#{'propname'}"
{noformat}
this silently fails as if sortBy= wasn't present:
{noformat}
sortBy="propname"
{noformat}
... and that looks like a bug to me.
For example, take the toy code:
{code:xml}
<h:form id="customerForm">
<rich:dataTable id="customerTable"
var="customer"
value="#{customers.model}"
rows="50">
<!-- Change `sortBy' below to sortBy="propname" and it'll fail, even
though the result should be IDENTICAL -->
<!-- Use sortBy="#{'propname'}" and it'll work -->
<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:title=Customers.java}
@Named
@RequestScoped
public class Customers {
// "CustomerDataModel" is a JPADataModel<Customer> as per
//
http://showcase.richfaces.org/richfaces/component-sample.jsf?demo=dataTable&sample=arrangeableModel&skin=blueSky
// 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 "propname";
}
// 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 "propname". Yet if we
write:
sortBy="propname"
no ArrangeableState is set on the backing Arrangeable ExtendedDataModel.
Writing the effectively identical:
sortBy="#{customers.sortBy}"
works, as does:
sortBy="#{'propname'}"
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=dataTable&sample=arrangeableModel&skin=blueSky
I haven't built a self-contained test case for this one as it seems trivial to
reproduce with anything you'd have lying around. If you need a test case let me
know and I'll chuck a Maven project together.
(Edit: multiple edits to figure out why JIRA was mangling the text. Turns out
anything within curly braces is treated as markup, even EL expressions with
single quotes immediately inside the braces. Sorry for the spam.)
was:
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:
{noformat}
sortBy="#{'propname'}"
{noformat}
this silently fails as if sortBy= wasn't present:
sortBy="propname"
... and that looks like a bug to me.
For example, take the toy code:
{code:xml}
<h:form id="customerForm">
<rich:dataTable id="customerTable"
var="customer"
value="#{customers.model}"
rows="50">
<!-- Change `sortBy' below to sortBy="propname" and it'll fail, even
though the result should be IDENTICAL -->
<!-- Use sortBy="#{'propname'}" and it'll work -->
<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:title=Customers.java}
@Named
@RequestScoped
public class Customers {
// "CustomerDataModel" is a JPADataModel<Customer> as per
//
http://showcase.richfaces.org/richfaces/component-sample.jsf?demo=dataTable&sample=arrangeableModel&skin=blueSky
// 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 "propname";
}
// 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 "propname". Yet if we
write:
sortBy="propname"
no ArrangeableState is set on the backing Arrangeable ExtendedDataModel.
Writing the effectively identical:
sortBy="#{customers.sortBy}"
works, as does:
sortBy="#{'propname'}"
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=dataTable&sample=arrangeableModel&skin=blueSky
(Edit: had to change "code" to "propname" because JIRA was getting confused by
the curly-braces surrounding the word "code")
> 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:
> {noformat}
> sortBy="#{'propname'}"
> {noformat}
> this silently fails as if sortBy= wasn't present:
> {noformat}
> sortBy="propname"
> {noformat}
> ... and that looks like a bug to me.
> For example, take the toy code:
> {code:xml}
> <h:form id="customerForm">
> <rich:dataTable id="customerTable"
> var="customer"
> value="#{customers.model}"
> rows="50">
> <!-- Change `sortBy' below to sortBy="propname" and it'll fail, even
> though the result should be IDENTICAL -->
> <!-- Use sortBy="#{'propname'}" and it'll work -->
> <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:title=Customers.java}
> @Named
> @RequestScoped
> public class Customers {
>
> // "CustomerDataModel" is a JPADataModel<Customer> as per
> //
> http://showcase.richfaces.org/richfaces/component-sample.jsf?demo=dataTable&sample=arrangeableModel&skin=blueSky
> // 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 "propname";
> }
> // 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 "propname". Yet if we
> write:
> sortBy="propname"
> no ArrangeableState is set on the backing Arrangeable ExtendedDataModel.
> Writing the effectively identical:
> sortBy="#{customers.sortBy}"
> works, as does:
> sortBy="#{'propname'}"
> 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=dataTable&sample=arrangeableModel&skin=blueSky
> I haven't built a self-contained test case for this one as it seems trivial
> to reproduce with anything you'd have lying around. If you need a test case
> let me know and I'll chuck a Maven project together.
> (Edit: multiple edits to figure out why JIRA was mangling the text. Turns out
> anything within curly braces is treated as markup, even EL expressions with
> single quotes immediately inside the braces. Sorry for the spam.)
--
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
_______________________________________________
richfaces-issues mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/richfaces-issues
