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. <[email protected]> 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. > >
