click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adrian A." <a.adrian.t...@gmail.com>
Subject Re: Proposal: drop stateful page support
Date Sun, 18 Jul 2010 08:21:56 GMT
> 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.


Mime
View raw message