Concerning this discussion: http://sourceforge.net/mailarchive/forum.php?thread_id=9955728&forum_id=42411
I gave this reply, and would like to have the developer votes, especially if they *don't* agree with the proposed change: It's actually pretty awfull. I don't really see the point of having to create the session upfront AND delegating the creation of the request cycle to the session which in turn delegates it to the factory which is set in the application. The problems I have with the current handling: 1) It seems to stem from an optimization (RequestCycle sets the Session as a final field so it doesn't have to use the thread local) only. I don't think we need the optimization and besides the same could have been accomplished by just lazy loading it. 2) I find it illogical that the session is there before the request(cycle). The other way around would be more initiutive and useful. 3) All that that one-liner delegation method does is tighten coupling. The factory method in session is meant for internal use only. We should loose it. What I propose: 1) Create RequestCycle before the session. 2) Use the Application's factory directly instead of passing via Session, and remove the method in Session. 3) The session is lazily created in getSession of Application. I propose to 'touch' that method in RequestCycle's constructor to ensure it is available for any user that wants to access it in the constructor of any custom RequestCycle. 4) Make the change ASAP/ before beta 2. Eelco ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
