its pretty accurate yes but a back link on V2 to V1 is a pretty special made thing Because there is normally not really a link to a previous page. Because on the javaside you don't know that really. But you can ask for a specific page version if you want.
johan On Nov 13, 2007 3:07 PM, Aqeel <[EMAIL PROTECTED]> wrote: > > 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/><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<http://nabble.com/> > . > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
