[jira] [Updated] (TAP5-1689) persistent sortcolumnid leads to exception with different model on the same page

["Jochen Kemnade (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/TAP5-1689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jochen Kemnade updated TAP5-1689:
---------------------------------

    Labels: bulk-close-candidate  (was: Grid Perist SortModel)

This issue has been last updated about 1.5 years ago, has no assignee, affects an old version of Tapestry that is not actively developed anymore, and is therefore prone to be bulk-closed in the near future.

If the issue still persists with the most recent development preview of Tapestry (5.4-beta-6, which is available from Maven Central), please update it as soon as possible. In the case of a feature request, please discuss it with the Tapestry developer community on the dev@tapestry.apache.org mailing list first.


> 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
>            Reporter: Wulf Wechsung
>            Priority: Minor
>              Labels: bulk-close-candidate
>   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 was sent by Atlassian JIRA
(v6.2#6252)