Major Description
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()); }