Figured this out.
Setting the unloadConfirmation to false here is useless, because Wicket only
examines that boolean in its show() method for the modal, at which point it
sets up unload event handlers based on true/false.
That event handler is already set by this point, so changing the boolean
h
Then you might need to update wicket.
-Matej
On 6/28/07, dukejansen <[EMAIL PROTECTED]> wrote:
>
> Tried this. It still gives the warning. :(
>
>
> James McLaughlin-3 wrote:
> >
> > Its a shameless hack, but you could try it in a setTimeout. Or possibly,
> > target.appendJavascript("Wicket.Windo
Tried this. It still gives the warning. :(
James McLaughlin-3 wrote:
>
> Its a shameless hack, but you could try it in a setTimeout. Or possibly,
> target.appendJavascript("Wicket.Window.unloadConfirmation=false;window.location.reload()")
> Otherwise, I believe the semantics of onClose make it
Its a shameless hack, but you could try it in a setTimeout. Or possibly,
target.appendJavascript("Wicket.Window.unloadConfirmation=false;window.location.reload()")
Otherwise, I believe the semantics of onClose make it necessary for
the modal to be around until onClose returns.
hth,
jim
On 5/31/
Any chance anyone has any input on this? I still think this is a bug in
Wicket, that I can't set Javascript to reload the page after the modal
window is closed, since the page still thinks the modal is open.
dukejansen wrote:
>
> Yup. That's why I was trying to do it using
> target.appendJavasc
Yup. That's why I was trying to do it using
target.appendJavascript("window.location.reload()") instead of doing the
setResponsePage server side...? Since I'm appending that Javascript AFTER
the 'close modal window' call, it seems like it should be able to close the
modal window client side, THEN
The problem is that when setResponsePage() is called, no appended
Javascript is evaluated. In fact, wicket doesn't process the ajax
response at all. Just sets window.location.
-Matej
On 5/9/07, dukejansen <[EMAIL PROTECTED]> wrote:
>
> Yeah, but I don't want to disable that warning. That warning
Yeah, but I don't want to disable that warning. That warning is valid if the
user really does try to navigate away while the modal is still being
displayed.
The problem is that I am actually closing the modal before I do the
redirect, so it shouldn't show the warning at all.
-Jason
Matej Knopp
There is a way that should also work in recent 1.x. To disable the
confirmation dialog you need to put this inside the page with modal
window:
Wicket.Window.unloadConfirmation=false;
-Matej
On 5/9/07, Arnout Engelen <[EMAIL PROTECTED]> wrote:
> dukejansen schreef:
> > My Ajax event handler ne
dukejansen schreef:
> My Ajax event handler needs to first close the current modal window and then
> refresh the entire page. Is there a better way to do this?
>
I once worked around something like this by putting the redirect in the
windowClosedCallback of the ModalWindow. That was sufficient
Ah. Maybe next time I'll try to acually read the whole email instead
of just the subject :) Sorry.
Matej, or anyone else with knowledge of modal windows... any ideas?
Eelco
On 5/9/07, Arnout Engelen <[EMAIL PROTECTED]> wrote:
>
> Eelco Hillenius schreef:
>
> Is there a better way to do this?
>
Eelco Hillenius schreef:
Is there a better way to do this?
Yep. Just call setResponsePage(MyPage.this) or
RequestCycle.get().setResponsePage or something similar. Only works in
1.3 I think.
Wouldn't that open MyPage inside the ModalWindow, since the javascript
for closing the ModalWind
> Is there a better way to do this?
Yep. Just call setResponsePage(MyPage.this) or
RequestCycle.get().setResponsePage or something similar. Only works in
1.3 I think.
Eelco
-
This SF.net email is sponsored by DB2 Express
Dow
Anyone have any recommendations for how I would go about getting my Ajax
event handler method to trigger a refresh of the current page on the client
side after it is done with the Ajax request? My Ajax event handler needs to
first close the current modal window and then refresh the entire page.
I
14 matches
Mail list logo
