"Leslie P. Polzer" <[email protected]> writes: > Jan Rychter wrote: >> It would need to be measured. I have suspicions that building widget >> trees on every request is expensive, especially as one usually makes >> database calls when building widgets. And in case of a bounce request or >> a bot request all that stuff sits around in memory until the session >> gets expired. > > You're right of course, but what I said was meant to only apply to > low-level session init, not the generation and storage of the whole > widget tree. > > So I think we should separate the issue of session generation from > the issue of eager widget tree creation
I agree with this... > (which a proper lazy navigation macro would solve). ...but not with this. No amount of lazy navigation macros will prevent you from generating the front page, which in many cases will be expensive to generate. I'd like to have a pre-generated cached version for clients without a session (they all get the same content anyway) and actually generate a new widget tree only when an action request comes in. You don't need to generate a per-session widget tree for pages accessible via navigation widgets, for example. >> Sounds good. My problem with (1) is that I don't understand why there >> are three calls to redirect in handle-client-request and what purpose >> they serve. > > My analysis of those three redirects, in order of occurence: > > (1) seems to be unnecessary. > > (2) seems slightly off too -- why would we need to prune the > session id from the URI if a cookie came in? Might warrant > some quick testing of what's going on and what removal > would change. > > (3) is the only one that makes sense to me: when we're talking > to a non-AJAX client (or in some other way get passed the > action via normal GET) we want to remove it from the URI > to avoid it being called again on refresh. > > In my opinion we should just remove the first two. Thanks, this makes a lot of sense. On my site I removed the first one a couple of days ago and set hunchentoot:*rewrite-for-session-urls* to nil. This got rid of the problem. So far things look good, although if you turn off cookies in your browser, the site will not work beyond the basic navigation (which is expected). I will kill (2) as well. I suspect (2) was a way of dealing with hunchentoot's URL rewriting, which gets in the way unless you turn it off. --J. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "weblocks" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/weblocks?hl=en -~----------~----~----~----~------~----~------~--~---
