Talking about ThreadLocals (TLs)... Recently Emond asked to use Servlet 3.0 for Wicket 6+ to be able to use the new async stuff. I still don't have a good use case for asynchronicity in Wicket page but I can see how the TLs will be unavailable after resuming the request processing. They are set/unset by WicketFilter for the thread that started the processing of the http request but later in the new thread the ThreadContext is empty. This is just something to think about for the future ...
On Thu, May 10, 2012 at 12:05 PM, Martijn Dashorst <[email protected]> wrote: > Overriding doesn't add bloat: the methods themselves are bloat in the > first place, given that one can readily call Session.get() and > Application.get(). > > I'm on the fence on whether or not they should be removed in a future > release: I like to be able to do new PropertyModel(this, > "session.user.name") as a shorthand, but I also dislike having all > these methods be part of the contract of a Component. > > Martijn > > On Wed, May 9, 2012 at 7:22 PM, Burton, Tom F (DOR) > <[email protected]> wrote: >> >> If allowing getApplication() to be overridden adds bloat why is it allowable >> to override getSession() ? >> >> Tom Burton >> >> Sent from my HTC >> >> ----- Reply message ----- >> From: "Christoph Leiter" <[email protected]> >> To: "[email protected]" <[email protected]> >> Subject: Allow overriding of getApplication/getPage >> Date: Wed, May 9, 2012 4:52 am >> >> >> >> >> On 09.05.2012 14:24, Martijn Dashorst wrote: >>> It adds bloat. Nobody (afaik) really likes these methods, as almost >>> the same functionality can be achieved by using Application.get() or >>> Session.get(); >> >> How is this bloat? I'm not proposing adding anything new, these methods >> are already there. >> >> IMO getApplication() is much nicer than MyApplication.get() because I >> don't need to invoke static methods (at least on the surface). >> >>> By opening up these methods for overriding, the contract is gone. >>> Components can't rely on the fact that getApplication() does just >>> that. >> >> Well, if one wants to shoot themselves in the foot... The contract is >> usually the method signature plus javadoc. If one does something else >> they break this contract deliberately and have to live with the >> consequences. >> >>> The use case you present for doing so is rather thin: there is nothing >>> preventing you from creating a getMyApplication() method that has the >>> correct type (as you already say you want to provide the correct type >>> in your own base classes—just create your own method that has the >>> correct type). >> >> That's right, but now I really have bloat, namely getApplication/Page twice. >> >> >> Christoph > > > > -- > Become a Wicket expert, learn from the best: http://wicketinaction.com -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
