Proposal: drop stateful page support

[Bob Schellink <sa...@gmail.com>]

Stateful pages have been giving me headaches ever since they were introduced in 1.4/1.5 and I'm
proposing that we remove them.

Stateful pages not only complicate the Click codebase but conceptually they are difficult to
understand compared to a stateless page which starts every request with a clean slate.

I also think they are too easy to use (and abuse). Consider this scenario: you have a table with
sort and paging state that you want to store while the user navigates between pages. The obvious
answer is to make the page stateful. However, not only is the table sort and paging state stored,
but the entire Page including its model Map, control List, i18n messages and every Page variable is
stored as well. And all you really wanted was to store 4 objects in the session.

I propose we deprecate the method Page.setStateful for 2.3.0-M1. Sadly there isn't any upgrade path
for existing code bases. Stateful pages simply have to be converted to stateless Pages and the view
state will have to be managed by the users or custom Controls that manage their state themselves.

Any objections? ;)

Regards,

Bob

Re: Proposal: drop stateful page support

[Bob Schellink <sa...@gmail.com>]

On 18/07/2010 18:21, Adrian A. wrote:
> This feature is since ages in there, and already just too many
> applications made use of it :(.
> (Had myself too converted some Wicket apps to Click)
> 
> I understand that it complicates the Click codebase, and it also has
> some bad impact on performance, 


I doubt it impacts performance. In fact it should be faster since the controls doesn't have to be
recreated.


but it is a very useful feature
> especially for RIA apps and for quick prototyping

I've not had any indication that Click is used or even a good fit for RIA applications. GWT, Flex
and Silverlight are better suited for RIA technologies.

> - people just love it


I've had the opposite experience while doing maintenance work on an existing Click project which
used stateful Pages. The problem I've found is that a stateful and stateless pages takes a very
different approach to write and so they end up looking and behaving different. Its like using two
different frameworks (think Struts+Wicket) in the same application. And because this is a "feature"
promoted by Click, developers feel compelled to use it.

Another problem is that stateful pages are full of edge cases and the Javadoc are littered with:

 Please note: don't do this on stateful pages

Over the weekend I've realized that FormTable doesn't work properly with stateful pages and might
not be possible to fix at all.

All these edge cases leads to leaky abstractions and turns a simple framework into a complex one.


> (and yes, they abuse it too, but they get the job done very fast this way).
> 
> Would it be possible at least to have this feature as an external
> project though (e.g. by an extended functionality of PageInterceptor or
> some other way) ?


I'm sure it would be possible to add stateful pages back in through an interceptor or some other
means. But at the end of the day its about the right tool for the right job. If an application needs
stateful pages isn't Wicket/Tapestry/JSF a better tool?

Bob

Re: Proposal: drop stateful page support

["Md. Jahid Shohel" <de...@gmail.com>]

It is true that stateful pages gives some flexibility on developers end.
That is one of the reason people likes Wicket. Also what Adrian suggested is
a good idea too. That way Click can get rid of stateful complicacies and
still have the statefulness on an extended project.


On Sun, Jul 18, 2010 at 10:21 AM, Adrian A. <a....@gmail.com> wrote:

> Stateful pages have been giving me headaches ever since they were
>> introduced in 1.4/1.5 and I'm
>> proposing that we remove them.
>>
>> Stateful pages not only complicate the Click codebase but conceptually
>> they are difficult to
>> understand compared to a stateless page which starts every request with a
>> clean slate.
>>
>> I also think they are too easy to use (and abuse). Consider this scenario:
>> you have a table with
>> sort and paging state that you want to store while the user navigates
>> between pages. The obvious
>> answer is to make the page stateful. However, not only is the table sort
>> and paging state stored,
>> but the entire Page including its model Map, control List, i18n messages
>> and every Page variable is
>> stored as well. And all you really wanted was to store 4 objects in the
>> session.
>>
>> I propose we deprecate the method Page.setStateful for 2.3.0-M1. Sadly
>> there isn't any upgrade path
>> for existing code bases. Stateful pages simply have to be converted to
>> stateless Pages and the view
>> state will have to be managed by the users or custom Controls that manage
>> their state themselves.
>>
>> Any objections? ;)
>>
> This feature is since ages in there, and already just too many applications
> made use of it :(.
> (Had myself too converted some Wicket apps to Click)
>
> I understand that it complicates the Click codebase, and it also has some
> bad impact on performance, but it is a very useful feature especially for
> RIA apps and for quick prototyping - people just love it (and yes, they
> abuse it too, but they get the job done very fast this way).
>
> Would it be possible at least to have this feature as an external project
> though (e.g. by an extended functionality of PageInterceptor or some other
> way) ?
>
> Adrian.
>
>

Re: Proposal: drop stateful page support

["Adrian A." <a....@gmail.com>]

> Stateful pages have been giving me headaches ever since they were introduced in 1.4/1.5 and I'm
> proposing that we remove them.
>
> Stateful pages not only complicate the Click codebase but conceptually they are difficult to
> understand compared to a stateless page which starts every request with a clean slate.
>
> I also think they are too easy to use (and abuse). Consider this scenario: you have a table with
> sort and paging state that you want to store while the user navigates between pages. The obvious
> answer is to make the page stateful. However, not only is the table sort and paging state stored,
> but the entire Page including its model Map, control List, i18n messages and every Page variable is
> stored as well. And all you really wanted was to store 4 objects in the session.
>
> I propose we deprecate the method Page.setStateful for 2.3.0-M1. Sadly there isn't any upgrade path
> for existing code bases. Stateful pages simply have to be converted to stateless Pages and the view
> state will have to be managed by the users or custom Controls that manage their state themselves.
>
> Any objections? ;)
This feature is since ages in there, and already just too many 
applications made use of it :(.
(Had myself too converted some Wicket apps to Click)

I understand that it complicates the Click codebase, and it also has 
some bad impact on performance, but it is a very useful feature 
especially for RIA apps and for quick prototyping - people just love it 
(and yes, they abuse it too, but they get the job done very fast this way).

Would it be possible at least to have this feature as an external 
project though (e.g. by an extended functionality of PageInterceptor or 
some other way) ?

Adrian.