persistent sortcolumnid leads to exception with different model on the same page
--------------------------------------------------------------------------------
Key: TAP5-1689
URL: https://issues.apache.org/jira/browse/TAP5-1689
Project: Tapestry 5
Issue Type: Bug
Components: tapestry-core
Affects Versions: 5.2.6
Reporter: Wulf Wechsung
Intro:
The T5 grid components stores the column that is currently being sorted in the
@Persist field sortColumnId. This works perfectly fine in the usual case where
the Grid always gets the same beanmodel for a given page.
Bug:
On a page that renders a Grid with a dynamic beanmodel ( for example a generic
List page that decides from it's activation context what kind of list to
display) the Grid will throw and exception in the following circumstances:
1) Page activation with parameter value A leads to a beanmodel with property
name A
2) Grid is sorted on property name A
3) Page activation with parameter value B that leads to a beanmodel with
property name B
-> Grid will throw an exception on SortModel.getSortConstraints() because
property name A (which is still stored in sortColumnId) does not exist in the
current beanmodel.
Solution:
in SortModel.getSortConstraints the following lines will solve the problem:
BeanModel dataModel = getDataModel();
if( !dataModel.getPropertyNames().contains(sortColumnId)) {
return Collections.emptyList();
}
General notes:
* many of the methods in BeanModel throw exception when a requested property
doesn't exist. While that's probably appropriate for most cases it would be
nice if all the beanmodel would support the if( exists) {} else{} pattern for
all it's methods that yield PropertyModels. For example, in the above code I'm
not sure if it's completely correct to check the columnId against a list of
names because the beanmodel does make a distinction but doesn't provide a
getPropertyIds() method.
* more generally, I feel that there is a small gap in the attribute persist
model of tapestry. Whenever a component needs to keep some state over requests
(such as AJAX requests) the methods of keeping that state all seem to have
drawbacks. @Persist will do the job of course but it doesn't (so it seems to
me) have good semantics for initializing, cleaning up and associating that
state. Ideally there would be some sort of abstraction that automatically maps
field persistence to how page requests flow for the user. For example, when a
user sees a partial page response or refreshes a page, it's still the same page
for him. I guess something that's tied to the page activation context and is
cleared once the same user requests a different page or context would do.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
