click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bob Schellink (JIRA)" <j...@apache.org>
Subject [jira] Created: (CLK-715) Stateful controls to replace stateful pages
Date Thu, 22 Jul 2010 15:46:49 GMT
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.


Mime
View raw message