i will check out the deadlock.But can i say that when you disable multi window support you can start testing with 2 tabsor you really have to specify the pagemap youreselfSo if you have use/test 2 tabs and both are in the same pagemap multiwindow support MUST be on.
Else it really won't work, that
I don't want to test with two tabs, but the fact is that my users
will be doing it regardless of what wicket supports. The expired
page is logical to me also, but it is not acceptable. Using your
example below, can't we leave page 2 in memory? The form action is
set to a separate
wicket
But that's exactly what we have build in. It's not totally fail safe -
clients need at least Javascript turned on but preferably also allow
cookies - but given the technology it's the best we can do for server
side store.
Eelco
On 4/29/06, Michael Day [EMAIL PROTECTED] wrote:
I don't want to
if you think users will do tabs or multiply browser for youre applicationdon't disable multi window support..only disable that if you know 99% sure that it is a single browser window/tab application.johan
On 4/29/06, Michael Day [EMAIL PROTECTED] wrote:
I don't want to test with two tabs, but the
I understand that we have a javascript/cookie solution, but I don't
like it. If I don't need back button support, why can't wicket deal
with multiple tabs/windows without javascript? Each time a page
containing a form is loaded, keep it in session as a separate object
- even if the page
On 4/29/06, Michael Day [EMAIL PROTECTED] wrote:
I understand that we have a javascript/cookie solution, but I don't
like it. If I don't need back button support, why can't wicket deal
with multiple tabs/windows without javascript? Each time a page
containing a form is loaded, keep it in
Btw, there has been some experimenting with client state saving for
Wicket. It seems like we could get that working. For issues like this,
it's the ultimate 'fix', though besides advantages there are of course
disadvantages, like the dependence on javascript, more bandwith use
and more processor
On Apr 29, 2006, at 12:01 PM, Eelco Hillenius wrote:
We need to know when we can ditch the pages too. In the strategy you
propose, we would ditch the second page in history - we always need to
keep one to have a path for callbacks (links and forms). This would
work exactly the same as doing
So the question is how can we keep multiple instances of the same
page in session, correct? What about keeping all pages (up to the
configured max) in the session until the session expires? Once the
number hits the max, remove the oldest (by time, not by path). So
if a user has two tabs open,
I'm not convinced this is a good solution, but I'm concerned that
most people are ignoring this problem. I love everything about
wicket, except this. In this regard, wicket is a giant step
backwards from other frameworks like webwork, struts, etc.
Most struts-like apps that I've seen had
Eelco Hillenius wrote:
I'm not convinced this is a good solution, but I'm concerned that
most people are ignoring this problem. I love everything about
wicket, except this. In this regard, wicket is a giant step
backwards from other frameworks like webwork, struts, etc.
Most struts-like apps
On Apr 29, 2006, at 12:41 PM, Eelco Hillenius wrote:
I'm not convinced this is a good solution, but I'm concerned that
most people are ignoring this problem. I love everything about
wicket, except this. In this regard, wicket is a giant step
backwards from other frameworks like webwork,
Well, every framework that manages the session state I know has problems
with keeping client in sync with server. Tracking browser windows/tabs
is difficult and unreliable. Wicket compared to the alternatives
currently does a very good (though hardly perfect) job.
The partial solution could
Just one to say one thing more for thisMultiPageWindow support doesn't have much to do with back button supportThose 2 are sperated issues. with multipage window support we are fixing things where the back button doesn't have to be touched at all.
johanOn 4/29/06, Michael Day [EMAIL PROTECTED]
Yep, I agree with Johan on the points he gave. ISessionStore was
created to abstract the actual storage of sessions, and the version we
have now is finally something that works (we needed a few iterations
to get it right). I'm using a custom session store for a project right
now btw.
Like Johan
Isn't what you describe just a rename of PageMap?So PageMap is Window ?INewBrowserWindowListener can be moved ot wicket.markup.htmlit is pretty much a internal listener inteface anyway.. It could be an internally scoped interface ...
But we can't make it package scope or something because some
On 4/29/06, Johan Compagner [EMAIL PROTECTED] wrote:
Isn't what you describe just a rename of PageMap?
So PageMap is Window ?
Well, for starters, I think having the proper naming makes a huge
difference in how you think about it and how people understand how it
is supposed to work.
I'd like to see a component level as well to support multi-request component storage, bound to a window. This would encapsulate component specific state which can be used over requests, and rolled back using our versioning strategy.
I still have to think about the details and more usecases, but I
On 4/30/06, Martijn Dashorst [EMAIL PROTECTED] wrote:
I'd like to see a component level as well to support multi-request component
storage, bound to a window. This would encapsulate component specific state
which can be used over requests, and rolled back using our versioning
strategy.
I think
Hi,
There is an issue when automatic multi-window support is turned off.
I have a form on a bookmarkable page. I loaded it in two tabs, then
submitted both. This caused the second one to show an expired page
error. When I click back and try to submit again, the connection
stalls.
i already entered a bug report for this
-Igor
On 4/28/06, Michael Day [EMAIL PROTECTED] wrote:
Hi,There is an issue when automatic multi-window support is turned off.I have a form on a bookmarkable page.I loaded it in two tabs, thensubmitted both.This caused the second one to show an expired page
21 matches
Mail list logo
