I think your example should be simplified to include only Page A. Imagine the Facebook profile page:
- You can add a wall post and after that you land on the same page with the new post shown on top. - This (in Wicket's way) should create 2 versions of your FB profile page. One with the posted message (v2) and the one before that (v1). - Now a back link from v2 should (if you have used PageMap) bring you to the version 1 state of the profile page. Johan, Please correct me if I am wrong. - Aqeel mfs wrote: > > In what context are you refering to the back button here...Lets say we > have two page instances of type "Page-A" through which we landed on > "Page-B" which has a back button on it, now clicking the back butoon > should load the "Page A" from the pageMap since its last accessed instance > of Page-A...isnt it ? Why do you say that pressing the back button once > will load the page from the disk... > > > > Johan Compagner wrote: >> >> if you press the back button only once then the page needs to come from >> disk. >> >> So if your users never use the back button then yes you only need to have >> the last accessed page in the pagemap. >> >> johan >> >> On Nov 9, 2007 10:36 PM, mfs <[EMAIL PROTECTED]> wrote: >> >>> >>> I agree..and i would say its mostly the nature of the applications which >>> would help determining whether storing the data in the wicket session >>> would >>> be a good idea or not... >>> >>> Further i believe that 99% of the times one just comes to the need of >>> accessing the last page-instances (lets say through back button link or >>> otherwise doing a refresh if on the same page)...i still couldnt think >>> of >>> scenarios where the older page-instances (which are being serialized) >>> would >>> come to help...If someone could discuss/point some of those >>> sceanrio/use-cases..that would be helpful..and would be able to better >>> justify the wicket's default behavior of serializing. >>> >>> Thanks and Regards, >>> >>> Farhan. >>> >>> >>> >>> Gwyn wrote: >>> > >>> > Hi, >>> > >>> > It's not hard to do it with Wicket, but I'm fairly sure that >>> > for the typical web-app, the metrics showed that the a re-request to >>> > database wasn't a big issue, whereas the gain in terms of reducing the >>> > session size was, especially where it needs replicating. >>> > >>> > As such, the recommendation is as it is, but it's not >>> > one-size-fits-all, and if you have a large enough percentage of >>> > non-DB-cachable operations in the DB-layer, you can store the results >>> > in the session, etc, without much of a problem. >>> > >>> > It's not going to be so built-in as to be trivial, though, as we want >>> > to make it clear that anyone doing that is going against the flow. >>> > >>> > On 09 November 2007, 9:03:31 AM, serban.balamaci wrote: >>> > sb> Most database expensive operations come from the result of stored >>> > sb> procedures(my current experience at least). A cache solution can >>> be >>> > sb> implemented by caching the method results with spring(in case of >>> using >>> > sb> spring) but is a heavy(difficult) thing to maintain that "cache" >>> per >>> > user - >>> > sb> http session is a nice and easy storage for that-. >>> > >>> > >>> > sb> Eelco Hillenius wrote: >>> >>> >>> >>>> You should use a second level cache to cache objects and queries >>> from >>> >>>> your database; and that's not Wicket's job, Wicket is a Web >>> framework. >>> >>>> >>> >>>> For example, use Hibernate + ehcache. >>> >>> >>> >>> Yep. That way you'll avoid redundancy in caching, and have caching >>> >>> regardless of whatever UI framework you're using. and using e.g. >>> >>> ehcache can do things for you like limit the RAM cache and overflow >>> to >>> >>> disk. Etc. >>> >>> >>> >>> Eelco >>> > >>> > >>> > -- >>> > /Gwyn >>> > >>> > >>> > --------------------------------------------------------------------- >>> > To unsubscribe, e-mail: [EMAIL PROTECTED] >>> > For additional commands, e-mail: [EMAIL PROTECTED] >>> > >>> > >>> > >>> >>> -- >>> View this message in context: >>> http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13675586 >>> Sent from the Wicket - User mailing list archive at >>> Nabble.com<http://nabble.com/> >>> . >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >> >> > > -- View this message in context: http://www.nabble.com/Disabling-serialization-storage-of-pages-in-session--tf4768006.html#a13726523 Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
