On Tue, Sep 1, 2009 at 9:50 PM, Geoff Callender<geoff.callender.jumpst...@gmail.com> wrote: > Good question. Yes, it does still seem to me to be best practice and no, I > don't see it breaking the back button. Can you give an example?
Assuming you use something else than session or client persistence and you initialize (create) an object, set it as a value of some page property in your setupRender(), then submit the form, press the back button and re-submit the formit, the object will be null (because it was initialized in setupRender() that was never invoked rather than onActivate()). Kalle > On 01/09/2009, at 8:37 AM, Kalle Korhonen wrote: > >> Hey Geoff, >> >> I recall reading at some point that you had recommended not using >> onActivate() for all initialization purposes, and sure enough, I dug >> it up and at >> http://jumpstart.doublenegative.com.au:8080/jumpstart/examples/navigation/onactivateandonpassivate/3 >> you say "It can be tempting to put lots of setup code into >> onActivate(...). However, if the stuff you are setting up is not >> needed for component event requests, consider putting it elsewhere, >> such as setupRender() or getter methods." >> >> Does that still reflect your current understanding of the best >> practices? The caveat with using setupRender() (or anything else >> except for onActivate()) is that even for non-ajax applications, it >> "breaks the back button", i.e. if a user goes back in history and say >> re-submits a form (for one reason or another) the objects required by >> the page/form are not initialized. Obviously it depends on the case >> what the application should do, but you loose half the benefits of >> redirect-after-post if your require a refresh before a page is usable >> again. Do you simple prefer rendering an an error in the back >> button/direct form submit case or do you generally do all >> initialization in onActivate()? >> >> Kalle >> >> >> On Tue, Aug 4, 2009 at 7:59 PM, Geoff >> Callender<geoff.callender.jumpst...@gmail.com> wrote: >>> >>> Hi all, >>> >>> JumpStart 4.4 is now available. It's a tidying up release: the >>> structure's >>> a bit neater and it uses the latest OpenEJB, ie. 3.1.1. >>> >>> Use it live: >>> >>> http://jumpstart.doublenegative.com.au:8080/jumpstart/ >>> >>> or download it: >>> >>> http://jumpstart.doublenegative.com.au >>> >>> And if someone can figure how to get Jetty/OpenEJB in Eclipse to use the >>> libs and classes in the WAR instead of having to be spoon-fed a >>> classpath, >>> then please let me know. I suspect it's a class-loading issue that might >>> soon be solved by http://code.google.com/p/embed-openejb-in-eclipse/. >>> >>> Cheers, >>> >>> Geoff >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
