1:45 a.m.
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">
<!-- Change `sortBy' below to sortBy="code" and
it'll fail, even though the result should be IDENTICAL -->
<!-- Use sortBy="#{'code'}" 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}
@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
1:47 a.m.
[
https://issues.jboss.org/browse/RF-12241?page=com.atlassian.jira.plugin.s...
]
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:
sortBy="#{'propname'}"
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}
<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}
@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 "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=dataTab...
(Edit: had to change "code" to "propname" because JIRA was getting
confused by the curly-braces surrounding the word "code")
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:
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">
<!-- Change `sortBy' below to sortBy="code" and
it'll fail, even though the result should be IDENTICAL -->
<!-- Use sortBy="#{'code'}" 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}
@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...
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="#{'propname'}"
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}
<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}
@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 "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=dataTab...
(Edit: had to change "code" to "propname" because JIRA was getting
confused by the curly-braces surrounding the word "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
1:49 a.m.
[
https://issues.jboss.org/browse/RF-12241?page=com.atlassian.jira.plugin.s...
]
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:
sortBy="#{'propname'}"
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=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 "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=dataTab...
(Edit: had to change "code" to "propname" because JIRA was getting
confused by the curly-braces surrounding the word "code")
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:
sortBy="#{'propname'}"
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}
<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}
@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 "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=dataTab...
(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:
sortBy="#{'propname'}"
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=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 "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=dataTab...
(Edit: had to change "code" to "propname" because JIRA was getting
confused by the curly-braces surrounding the word "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
1:51 a.m.
[
https://issues.jboss.org/browse/RF-12241?page=com.atlassian.jira.plugin.s...
]
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:
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=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 "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=dataTab...
(Edit: had to change "code" to "propname" because JIRA was getting
confused by the curly-braces surrounding the word "code")
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:
sortBy="#{'propname'}"
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=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 "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=dataTab...
(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:
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=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 "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=dataTab...
(Edit: had to change "code" to "propname" because JIRA was getting
confused by the curly-braces surrounding the word "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
1:51 a.m.
[
https://issues.jboss.org/browse/RF-12241?page=com.atlassian.jira.plugin.s...
]
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:
sortBy="#{'propname'}"
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=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 "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=dataTab...
(Edit: had to change "code" to "propname" because JIRA was getting
confused by the curly-braces surrounding the word "code")
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:
sortBy="#{'propname'}"
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=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 "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=dataTab...
(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:
sortBy="#{'propname'}"
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=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 "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=dataTab...
(Edit: had to change "code" to "propname" because JIRA was getting
confused by the curly-braces surrounding the word "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
1:55 a.m.
[
https://issues.jboss.org/browse/RF-12241?page=com.atlassian.jira.plugin.s...
]
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=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 "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=dataTab...
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=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 "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=dataTab...
(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=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 "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=dataTab...
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
5:26 p.m.
[
https://issues.jboss.org/browse/RF-12241?page=com.atlassian.jira.plugin.s...
]
Brian Leathem reassigned RF-12241:
----------------------------------
Assignee: Pavol Pitonak
QE, please confirm
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
Assignee: Pavol Pitonak
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=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 "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=dataTab...
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
9:54 p.m.
[
https://issues.jboss.org/browse/RF-12241?page=com.atlassian.jira.plugin.s...
]
Craig Ringer commented on RF-12241:
-----------------------------------
Note that while my example uses ${} for sortBy, the problem remains when it's changed
to #{}; in any case, it should work with a *constant* literal too, that's the whole
point.
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
Assignee: Pavol Pitonak
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=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 "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=dataTab...
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
11 a.m.
[
https://issues.jboss.org/browse/RF-12241?page=com.atlassian.jira.plugin.s...
]
Pavol Pitonak reassigned RF-12241:
----------------------------------
Assignee: Jan Papousek (was: Pavol Pitonak)
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
Assignee: Jan Papousek
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=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 "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=dataTab...
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
6:40 a.m.
[
https://issues.jboss.org/browse/RF-12241?page=com.atlassian.jira.plugin.s...
]
Jan Papousek updated RF-12241:
------------------------------
Attachment: richfaces-sandbox.zip
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
Assignee: Jan Papousek
Priority: Minor
Attachments: richfaces-sandbox.zip
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=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 "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=dataTab...
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
6:56 a.m.
[
https://issues.jboss.org/browse/RF-12241?page=com.atlassian.jira.plugin.s...
]
Jan Papousek resolved RF-12241.
-------------------------------
Resolution: Cannot Reproduce Bug
Hi Craig,
I have i little problem to reproduce the described behaviour. This is my only working code
sample (and matches to the
[documentation|http://docs.jboss.org/richfaces/latest_4_X/vdldoc/rich/colu...] :
{code}
<rich:column sortBy="#{customer.name}"
sortOrder="#{customers.sortOrder}" id="code">
...
</rich:column>
{code}
The following code samples don't work:
{code}
<rich:column sortBy="#{'name'}"
sortOrder="#{customers.sortOrder}" id="code">
...
</rich:column>
{code}
{code}
<rich:column sortBy="name" sortOrder="#{customers.sortOrder}"
id="code">
...
</rich:column>
{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
Assignee: Jan Papousek
Priority: Minor
Attachments: richfaces-sandbox.zip
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=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 "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=dataTab...
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
4497
days inactive
4586
days old
richfaces-issues@lists.jboss.org
10 comments
4 participants
participants (4)
-
Brian Leathem (JIRA) -
Craig Ringer (JIRA)
-
Jan Papousek (JIRA)
-
Pavol Pitonak (JIRA)