its not the lasst access page of a Page. Its the last access page of a page in a pagemap what ever it is PageA or PageB or PageZ
On Nov 10, 2007 12:31 AM, mfs <[EMAIL PROTECTED]> 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#a13677131 > 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] > >
