Hi Johan,
as I mentioned earlier, I realise that long operations shouldn't be done in
the request thread. But there are some cases where it's hard to guarantee
that operations can't take long, and I want to make sure we cope well with
exceptional cases too.
I didn't fully understand your last
Then you dont throw the right thing, you should set a page as the
response opage thats in a different pagemap
On 9/8/08, Jan Stette [EMAIL PROTECTED] wrote:
Hi Johan,
as I mentioned earlier, I realise that long operations shouldn't be done in
the request thread. But there are some cases
You have to redirect onces.
Just throw a resartresponseexception in the constructor and let a new
page be created. It are all landing pages anyway so thats
bookmarkable.
But to make this thread even simpeler. Just dont have long running
stuff in the request thread
On 9/5/08, Jan Stette [EMAIL
Hi Johan,
I've seen the code in WebPage.onNewBrowserWindow(). The thing I'm having a
problem figuring out is where to hook in this code. I can't see that I can
do this in the constructor of a page as you suggest. In the constructor the
page hasn't been fully constructed yet so I can't see that
Johan,
I've had a look at doing the workaround you suggest, but I don't know
Wicket's internals enough to fully understand where to plug it in. In the
constructor of a page, I can check the page map name, but how would I do the
redirect here? Conversely, I can override onBeginRequest() in the
First try to look at the newbrowser window check that we have in webpage.
Dont know if you can all do those things (clone the page and set
another pagemap)
What you could do is int the page const check pagemap, if default then
create the same page as you are on but then with a different pagemap
And even with that check it will not work.
If you open a new tab then the first page wicket will render when you
type in an url will be the defaul pagemap. Only on the first page
rendered we know that we have to redirect. So that first page will be
blocked. The only thing that could maybe help is
Thanks for your answers, Matej and Johan.
Matej: we are running with multi-window support on, and store per-window
related navigation in the session keyed on page map name. This works fine
most of the time.
Johan: I've been stepping through the Wicket code and studying the docs to
understand
Yes your observation is exactly what i described.
What you can do is for example check in the constructor (with pagemap
param) or in onbegin request (before render) of a page, if the pagemap
is the default, if it is create the same page with a new pagemap and
redicect to that one.
Whay you want
I'm having a problem with the following scenario:
1. A user logs into our Wicket application and starts using it.
2. The user clicks on a link which kicks off a potentially long-running
operation.
3. While getting bored with waiting for this to complete, the user copies
the URL from her
Hi,
the long running process should be executed in separate thread. You
can make wicket periodically poll for result (via ajax). It is
generally not a good idea to run action that potentially can take long
time to complete from a request thread.
-Matej
On Thu, Aug 28, 2008 at 8:42 PM, Jan
I agree, that's a better long-term fix. Even so, isn't it wrong that the
request from a new window is locked waiting on the other window's page map -
I would have thought the new window should have ended up with its own page
map?
Regards,
Jan
2008/8/29 Matej Knopp [EMAIL PROTECTED]
Hi,
the
Only if multi window support is on (which is off by default with
secondlevelcachesessionstore). The multiwindow support is more or less
a hack, because HTTP doesn't really provide any means to detect
browser windows/tabs.
-Matej
On Fri, Aug 29, 2008 at 2:28 AM, Jan Stette [EMAIL PROTECTED]
13 matches
Mail list logo
