You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Wulf Wechsung (Created) (JIRA)" <ji...@apache.org> on 2011/10/11 17:23:11 UTC
[jira] [Created] (TAP5-1689) persistent sortcolumnid leads to
exception with different model on the same page
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
[jira] [Updated] (TAP5-1689) persistent sortcolumnid leads to
exception with different model on the same page
Posted by "Wulf Wechsung (Updated) (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Updated] (TAP5-1689) persistent sortcolumnid leads to
exception with different model on the same page
Posted by "Wulf Wechsung (Updated) (JIRA)" <ji...@apache.org>.
[ 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