You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@click.apache.org by Tim Hooper <th...@gmail.com> on 2011/08/24 15:44:28 UTC

Page State

I find that click works excellent on relitively simple pages, but seems to be 
very difficult to work with (ie. managing page/variable state) on pages with
multiple controls and request parameters.

For example, I have a page that takes in multiple request parameters 
(mode,month,year,department,facility,etc) ,and has a form and two tables.  This 
page is designed that users can select records from the tables, which populates 
the form with data that can be updated (I am not using ajax for this, instead I 
am posting back to the page).  

My gripe is that when a user posts the form to save a record, click executes the 
pages constructor, the onInit, the onGet, onRender, etc.  rather than just the 
onSaveRecord() method that I defined for my form.  This means that I have to put 
all kinds of hidden fields in my form to post the data back to satisfy the 
constructor, onInit, onGet, etc.  as well as checkst to determine if this is the 
first time I've gone through...or if it is a real submission of the form.  in 
general...page state is just very diffucult for non-trivial pages.

Am I missing something with the framework that can make this easier?  

Thanks.

Tim


RE: Page State

Posted by Nicholas Dierauf <ni...@autodesk.com>.
Conceptually, I like the idea of a stateless framework. Practically, I find applications difficult to debug and maintain using the Click framework, especially with complex nested Click controls. I find that I am spending more time wrestling with the Click framework than on my actual application. I think that part of the reason for this is that Apache Click still feels like a "young" framework. The documentation is good, but not complete. Best-practices for complex, nested control, AJAX-based applications need to be fleshed out and documented. The user forum is good, but not all of the hard questions have been asked and answered (kudos though to forum members for responding quickly and knowledgably when tough questions are asked!).

The recursive nature of cycling through page and control constructors  and methods (onInit, onRender, etc) make debugging/maintaining applications difficult, especially with multiple nested Click controls. I don't know if there is an easier way to process stateless objects; I'm sure that the architects of the framework have done a great job. 

As an aside, I have found that judicious request-scope caching of certain "ancestor" objects containing information used by "child" objects helps reduce the need to reconstruct them later by the child controls.

Cheers,
Nick.


-----Original Message-----
From: Bob Schellink [mailto:sabob1@gmail.com] 
Sent: Wednesday, August 24, 2011 10:29 AM
To: user@click.apache.org
Subject: Re: Page State

Hi Tim,

Click is a stateless framework meaning no UI state is store in the session. This makes things easy to understand and debug but does limit how easily screen complexity can scale. In order for Click to do what you want the framework would need to store the Page and all controls in memory for every user. And all data connected to the page or control would also be pulled into memory. There are exiting Java frameworks which took this approach such as Wicket, Tapestry and JSF. These frameworks provides a stateful environment.

In the past Click had the concept of a stateful page but it maintenance increase as it is difficult to debug and follow the program flow.

Click does provide stateful controls which might help in your case if you need to store the Field values between requests.

Personally I split pages into SearchPages and EditPages eg: CustomerSearchPage/CustgomerEditPage. 
This breaks the master/detail pattern into two separate pages make the page smaller and more focused.

If you really want everything in one page then you'll need to add hidden fields to pass values around or store the Form Fields in the session.

Ajax requests still executes the Page constructor and onInit phases (otherwise Click won't know which control to target) so Ajax won't help you in this case. While Ajax is useful it does complicate the page.

regards

Bob

On 2011/08/24 19:03 PM, Tim Hooper wrote:
> Damian Penney<damian<at>  penney.org>  writes:
>
>>
>> I'm a relative newbie with regards Click but if you resubmit back to 
>> the
> page then you are indeed recreating it. To avoid the get (what do you 
> have in there?) your form action could post the info instead so onPost 
> would be called instead.
>>
>>
>>
>> What hidden fields are you finding yourself having to add?
> I am adding fields to control which records show up in my tables 
> (year, department, facility, month,etc.)  I agree with you that 
> resubmitting back HAS to recreate the page...so the page life cycle needs to complete.
> I just wish there was a way to submit the form data to my 
> onSubmitClicked() method and not go through the page constructor, onInit(), etc.
> I guess I would need to use Ajax to do that?
>
>


Re: Page State

Posted by Damian Penney <da...@penney.org>.
My guess is that the problem isn't really the fact that the constructor and
onInit is called but rather that the subsequent page that is generated is
incorrect if the hidden fields aren't passed. You do avoid that issue with
ajax because you aren't actually re-rendering your page.



On Wed, Aug 24, 2011 at 10:28 AM, Bob Schellink <sa...@gmail.com> wrote:

> Hi Tim,
>
> Click is a stateless framework meaning no UI state is store in the session.
> This makes things easy to understand and debug but does limit how easily
> screen complexity can scale. In order for Click to do what you want the
> framework would need to store the Page and all controls in memory for every
> user. And all data connected to the page or control would also be pulled
> into memory. There are exiting Java frameworks which took this approach such
> as Wicket, Tapestry and JSF. These frameworks provides a stateful
> environment.
>
> In the past Click had the concept of a stateful page but it maintenance
> increase as it is difficult to debug and follow the program flow.
>
> Click does provide stateful controls which might help in your case if you
> need to store the Field values between requests.
>
> Personally I split pages into SearchPages and EditPages eg:
> CustomerSearchPage/**CustgomerEditPage. This breaks the master/detail
> pattern into two separate pages make the page smaller and more focused.
>
> If you really want everything in one page then you'll need to add hidden
> fields to pass values around or store the Form Fields in the session.
>
> Ajax requests still executes the Page constructor and onInit phases
> (otherwise Click won't know which control to target) so Ajax won't help you
> in this case. While Ajax is useful it does complicate the page.
>
> regards
>
> Bob
>
>
> On 2011/08/24 19:03 PM, Tim Hooper wrote:
>
>> Damian Penney<damian<at>  penney.org>  writes:
>>
>>
>>> I'm a relative newbie with regards Click but if you resubmit back to the
>>>
>> page then you are indeed recreating it. To avoid the get (what do you have
>> in there?) your form action could post the info instead so onPost would be
>> called instead.
>>
>>>
>>>
>>>
>>> What hidden fields are you finding yourself having to add?
>>>
>> I am adding fields to control which records show up in my tables (year,
>> department, facility, month,etc.)  I agree with you that resubmitting
>> back HAS to recreate the page...so the page life cycle needs to complete.
>> I just wish there was a way to submit the form data to my
>> onSubmitClicked()
>> method and not go through the page constructor, onInit(), etc.
>> I guess I would need to use Ajax to do that?
>>
>>
>>
>

Re: Page State

Posted by Bob Schellink <sa...@gmail.com>.
Hi Tim,

Click is a stateless framework meaning no UI state is store in the session. This makes things easy 
to understand and debug but does limit how easily screen complexity can scale. In order for Click to 
do what you want the framework would need to store the Page and all controls in memory for every 
user. And all data connected to the page or control would also be pulled into memory. There are 
exiting Java frameworks which took this approach such as Wicket, Tapestry and JSF. These frameworks 
provides a stateful environment.

In the past Click had the concept of a stateful page but it maintenance increase as it is difficult 
to debug and follow the program flow.

Click does provide stateful controls which might help in your case if you need to store the Field 
values between requests.

Personally I split pages into SearchPages and EditPages eg: CustomerSearchPage/CustgomerEditPage. 
This breaks the master/detail pattern into two separate pages make the page smaller and more focused.

If you really want everything in one page then you'll need to add hidden fields to pass values 
around or store the Form Fields in the session.

Ajax requests still executes the Page constructor and onInit phases (otherwise Click won't know 
which control to target) so Ajax won't help you in this case. While Ajax is useful it does 
complicate the page.

regards

Bob

On 2011/08/24 19:03 PM, Tim Hooper wrote:
> Damian Penney<damian<at>  penney.org>  writes:
>
>>
>> I'm a relative newbie with regards Click but if you resubmit back to the
> page then you are indeed recreating it. To avoid the get (what do you have
> in there?) your form action could post the info instead so onPost would be
> called instead.
>>
>>
>>
>> What hidden fields are you finding yourself having to add?
> I am adding fields to control which records show up in my tables (year,
> department, facility, month,etc.)  I agree with you that resubmitting
> back HAS to recreate the page...so the page life cycle needs to complete.
> I just wish there was a way to submit the form data to my onSubmitClicked()
> method and not go through the page constructor, onInit(), etc.
> I guess I would need to use Ajax to do that?
>
>


Re: Page State

Posted by Damian Penney <da...@penney.org>.
Yes - ajax is your friend on that front and it makes for a nice snappy
interface. jQuery has some very easy to use ajax functionality.


On Wed, Aug 24, 2011 at 10:03 AM, Tim Hooper <th...@gmail.com> wrote:

> Damian Penney <damian <at> penney.org> writes:
>
> >
> > I'm a relative newbie with regards Click but if you resubmit back to the
> page then you are indeed recreating it. To avoid the get (what do you have
> in there?) your form action could post the info instead so onPost would be
> called instead.
> >
> >
> >
> > What hidden fields are you finding yourself having to add?
> I am adding fields to control which records show up in my tables (year,
> department, facility, month,etc.)  I agree with you that resubmitting
> back HAS to recreate the page...so the page life cycle needs to complete.
> I just wish there was a way to submit the form data to my onSubmitClicked()
> method and not go through the page constructor, onInit(), etc.
> I guess I would need to use Ajax to do that?
>
>

Re: Page State

Posted by Tim Hooper <th...@gmail.com>.
Damian Penney <damian <at> penney.org> writes:

> 
> I'm a relative newbie with regards Click but if you resubmit back to the 
page then you are indeed recreating it. To avoid the get (what do you have 
in there?) your form action could post the info instead so onPost would be 
called instead.
> 
> 
> 
> What hidden fields are you finding yourself having to add?
I am adding fields to control which records show up in my tables (year,
department, facility, month,etc.)  I agree with you that resubmitting 
back HAS to recreate the page...so the page life cycle needs to complete.  
I just wish there was a way to submit the form data to my onSubmitClicked() 
method and not go through the page constructor, onInit(), etc.  
I guess I would need to use Ajax to do that?


Re: Page State

Posted by Damian Penney <da...@penney.org>.
I'm a relative newbie with regards Click but if you resubmit back to the
page then you are indeed recreating it. To avoid the get (what do you have
in there?) your form action could post the info instead so onPost would be
called instead.

What hidden fields are you finding yourself having to add?


On Wed, Aug 24, 2011 at 6:44 AM, Tim Hooper <th...@gmail.com> wrote:

> I find that click works excellent on relitively simple pages, but seems to
> be
> very difficult to work with (ie. managing page/variable state) on pages
> with
> multiple controls and request parameters.
>
> For example, I have a page that takes in multiple request parameters
> (mode,month,year,department,facility,etc) ,and has a form and two tables.
>  This
> page is designed that users can select records from the tables, which
> populates
> the form with data that can be updated (I am not using ajax for this,
> instead I
> am posting back to the page).
>
> My gripe is that when a user posts the form to save a record, click
> executes the
> pages constructor, the onInit, the onGet, onRender, etc.  rather than just
> the
> onSaveRecord() method that I defined for my form.  This means that I have
> to put
> all kinds of hidden fields in my form to post the data back to satisfy the
> constructor, onInit, onGet, etc.  as well as checkst to determine if this
> is the
> first time I've gone through...or if it is a real submission of the form.
>  in
> general...page state is just very diffucult for non-trivial pages.
>
> Am I missing something with the framework that can make this easier?
>
> Thanks.
>
> Tim
>
>