you can mount a requestmapper that creates threadlocal instances of
handlers :) or has a sync block on session.get(). the possibilities
are endless.
-igor
On Tue, Oct 6, 2009 at 5:20 PM, Peter Ertl <pe...@gmx.org> wrote:
> also it would be great to provide some easy mechanism of synchronizing
> RequestMappers with the wicket session (e.g. rendering data that depends on
> the current user info in the session).
>
> Am 07.10.2009 um 02:11 schrieb Peter Ertl:
>
>> +1.000 for that
>>
>> mount RequestHandler will allow any kind of browser output (resources,
>> pages, server side redirects to external urls, etc.)
>>
>> being able to access placeholders from resources will be great :-)
>>
>> thinking of something like:
>>
>> mount(new MountedMapper("image/${name}.${format}", imageResourceHandler)
>>
>>
>> Am 06.10.2009 um 17:13 schrieb Igor Vaynberg:
>>
>>> ahha, here is something we need to change. we should have a
>>> mountedmapper that allows one to mount a requesthandler rather then a
>>> page. the user should not go as far as having to implement
>>> requestablepage, there are a lot of extraneous methods there if all
>>> you want to do is handle the request yourself.
>>>
>>> -igor
>>>
>>> On Tue, Oct 6, 2009 at 3:08 AM, Daniel Stoch <daniel.st...@gmail.com>
>>> wrote:
>>>>
>>>> The great thing for me is that I'll be able to mounting something that
>>>> just implements RequestablePage interface, not only a Page class
>>>> descendants (if I've read this code correctly :)). It allows to handle
>>>> navigation more flexible and it allows to avoid creating hard to
>>>> maintain page class hierarchies.
>>>>
>>>> --
>>>> Daniel
>>>>
>
>
