click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bob Schellink (JIRA)" <>
Subject [jira] Resolved: (CLK-715) Stateful controls to replace stateful pages
Date Sat, 13 Nov 2010 11:14:13 GMT


Bob Schellink resolved CLK-715.

    Resolution: Fixed


> Stateful controls to replace stateful pages
> -------------------------------------------
>                 Key: CLK-715
>                 URL:
>             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.

View raw message