correct.
Johan Compagner wrote: > > on curious thing: why do you already sign/set a cookie at the moment the > session is constructed > it is the first page that is getting hit then you already have a user? > > johan > > > On 4/14/07, Jonathan Locke <[EMAIL PROTECTED]> wrote: >> >> >> >> Yeah, that's it. Sorry if I failed to convey the why's very well. >> I was really exhausted (12 hour day, little sleep) when I tried >> to write that WIKI explanation. So here's more: >> >> The problem we have, that I think others will eventually run into, >> is that you may want to sign a user in during session construction, >> most likely under testing, but there could be other reasons. Until >> this change was made, it was actually impossible to do this because >> you could not set a cookie in your session constructor at all (testing >> or not) because the request cycle (which holds the response for >> the current thread to set a cookie on) was being constructed after >> session construction using a factory contained in the session (which >> is a very bad location for this, in hindsight). >> >> We've disliked this organization of things for a long time, but it >> was this use case that finally pushed us to make this change. >> It was certainly possible to hack around this by creating a custom >> request cycle factory (which would mean several times as many >> lines and a very non-intuitive solution for others who run into this) >> and sweeping this all under the rug with business-as-usual, but >> the benefits of doing this right were finally too hard to ignore. >> We actually shrank the amount of code considerably with this >> change. The result is better, faster, smaller and less confusing >> for both users and developers of Wicket. >> >> >> Eelco Hillenius wrote: >> > >> > >> http://cwiki.apache.org/WICKET/migrate-13.html#Migrate-1.3-RequestCycle%252CIRequestCycleFactory%252CSession%252CIPageMapandPageMapchanges >> >> > helps. >> >> >> >> this says what, but not the why. >> > >> > Ok, I thought it was obvious from just looking at the changes, but here >> we >> > go. >> > >> > * We got rid of getDefaultRequestCycleFactory and replaced it by >> > getRequestCycleFactory in Application, and we don't create the request >> > cycle through the session anymore. That's what but if you pull out >> > your API elegance tentacles, it's the why as well. >> > * We only create a session instance when we really need to (it's >> > created lazily). Possibly a slight optimization. The creation and >> > registering of the session is all in the right place now. Not >> > scattered througout wicket filter and application, but just in the >> > session itself. >> > * The request cycle is now available in the Session's constructor. I >> > believe this was what Jonathan needed for better testing support, but >> > I'm not sure. >> > * PageMaps were updated for the session on every request, and held a >> > reference to the session object. This wasn't needed at all, so this is >> > a cleanup and efficiency improvement. >> > >> > Eelco >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/why-are-we-suddenly-creating-2-request-cycles--tf3557832.html#a9995066 >> Sent from the Wicket - Dev mailing list archive at Nabble.com. >> >> > > -- View this message in context: http://www.nabble.com/why-are-we-suddenly-creating-2-request-cycles--tf3557832.html#a9996630 Sent from the Wicket - Dev mailing list archive at Nabble.com.
