[
https://issues.apache.org/jira/browse/CLK-715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bob Schellink resolved CLK-715.
-------------------------------
Resolution: Fixed
fixed
> Stateful controls to replace stateful pages
> -------------------------------------------
>
> Key: CLK-715
> URL: https://issues.apache.org/jira/browse/CLK-715
> Project: Click
> Issue Type: New Feature
> Components: core
> Affects Versions: 2.2.0
> Reporter: Bob Schellink
> Assignee: Bob Schellink
> Fix For: 2.3.0-M1
>
>
> Click has been supporting stateful pages for while but these have serious
> maintenance and memory issues. Stateful pages also create an inconsistent
> Click experience. To develop stateful pages is conceptually much different
> from stateless ones since you use the same Page and Control instances from
> the previous request. The Page constructor is not invoked for subsequent
> requests but the other life cycle events are. This leads to code littered
> with guarding checks to ensure duplicate controls are not added to containers.
> The main idea behind stateful pages was to create a simple and transparent
> way for developers to save state. In other words the state should be handled
> implicitly by the framework. I think we missed the sweet spot on this one by
> trying to make things too simple and allowing no control over the state
> managing.
> Since Click is predominantly a stateless framework the majority of use cases
> could would involve saving/restoring simple values such as:
> - table sort column name and current page number
> - form fields values
> - active panel name in a TabbedPanel
> Instead of trying to hide the complexity my suggestion is to fully expose
> state management to the developer. Click is all about server-side development
> (not desktop) and I would like to have full control over what goes and does
> not go into the application session. This kind of transparency will give me
> greater confidence when using stateful controls. If something doesn't work
> the debugger will quickly point out where things are going wrong. It would
> also be easier to debug the session content since it will mostly consist of
> primitives and strings.
> My current thinking is to expose an interface Stateful which Controls can
> implement:
> public void restoreState(Context context)
> public void saveState(Context context)
> public void clearState(Context context)
> Usage:
> public MyPage ...
> public void onInit() {
> table.restoreState(getContext());
> }
> public void onRender() {
> table.saveState(getContext());
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
