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:[email protected]] Sent: Wednesday, August 24, 2011 10:29 AM To: [email protected] 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? > >
