Hi Marco,
Comments inline:
On 21/07/2010 02:41, Marco Gattei wrote:
> I've several statuful pages in five or 6 projects ....
>
> Tipical scenario is when i have a searchable list of items from the user.
>
> I use a form to allow user to filter the items in the table.
> the user can select viewable columns too.
> Usually we talk about 8 -12 elements plus control for each column.
> Then the user can click on an item and go to a page where he can
> edit/mnipulate data .... then he gets back to the page.
Assuming that stateful pages are removed, would your use cases be satisfied if
the Form and Table
controls could store their internal state? So instead of marking the Page as
stateful you could
store/load state from the Form/Table. For example:
onInit() {
form.loadState(); // load the field values from the session
table.loadState(); // load pageNumber, column and ascending variables from
session
}
onRender() {
form.saveState();
table.saveState();
}
This is more lines of code than simply marking the Page as stateful, but on the
flip side the Page
event flow becomes consistent again. Every request you start with a new Page
and new Controls.
However the responsibility now lies with the developer to load and save Control
state.
I'm probably going to sound like a salesman here but I've recently done
maintenance on a Click
application which used both stateful and stateless pages. From a maintenance
perspective (someone
who didn't author the original application) I was surprised by the conceptual
difference between a
stateful and stateless Page. To the casual observer the Java code on a
Stateless and Stateful page
might look similar but I've found the code to be quite fragile. For example the
ordering in which
things are done is extremely important. I've found alot of checks in the
stateful Page to guard
against replaying certain code paths. It's quite easy to break the Page if you
don't pay attention.
> Having stateful pages is a quick way form me to store navigation
> information in session,
> which i find more pratical than passing around as request attribute (
> but i'm aware this is quite a personal feeling ).
>
> I've been using click from versione 0.19, and i admit i was very happy
> when Malcolm introduces stateful pages.
> On other and I've to admit that to managed stateful pages to work
> properly requires a great deal of insigth on
> Click pages lifecycle .... which took me a while to reach....
Agreed, but knowing the lifecycle is a good thing :) What has me worried more
is the amount of edge
cases not supported by stateful pages. For example SpringServlet cannot
reliably inject services
into stateful pages, FormTable doesn't work well either.
> I found Click very found and productive to use, expecially when
> combined with Cayenne.
> The only thing i complain it's not lack of visibility of the framework,
> but maybe there has bees too much changes in the api....
> Sometimes it's quite hard to keep the pace :-D
Yes this is a concern. I'd still like to see some proper Ajax support in the
next release,
especially when one considers the impact HTML5 is having. Once Ajax support is
added I think Click
core is fairly feature complete.
> --
> Marco
Thanks for sharing your experience. Appreciate the feedback.
Kind regards
Bob
