[
https://issues.apache.org/jira/browse/TAP5-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Wulf Wechsung updated TAP5-1689:
--------------------------------
Labels: Gird Perist SortModel (was: )
Priority: Minor (was: Major)
Remaining Estimate: 24h
Original Estimate: 24h
> 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
> Priority: Minor
> Labels: Grid, Perist, SortModel
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> 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
