wicket-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Per Lundholm <per.lundh...@gmail.com>
Subject Re: Detaching and ModalWindow causes race condition
Date Sat, 04 Jul 2009 10:40:13 GMT
Sorry Martijn but you are so ahead of me that I can't even follow the
suggestion you make.

However, I just can support you on not using modal windows. We have a
back office application written in Swing that use modal windows a lot
and it is just getting worse by each feature added.

Modal windows are really a last resort and should not be used at all,
if you can avoid it. What I have seen is that they tend to grow in
functionality over time and suddenly you are faced with the question:
"should I put a modal window here, oh, I am already in a modal

(Ranting further), modal windows are primarily for non-expert users
that need guidance when you wish to be certain that they know the
implications of what they do. There should be nothing but some
information and a yes/no question.

Apparently, it seems that the users are pushing you around and
customer is always right, so what to do? I suggest a step back and
present a complete new style of interaction that would give users a
much better flow in the interaction than now.

Thanks for reading. :-)


On Fri, Jul 3, 2009 at 3:11 PM, Martijn
Dashorst<martijn.dashorst@gmail.com> wrote:
> In our apps we (wrongfully IMO) make heavily use of ModalWindow (our
> users seem to like them). We ran into an issue/race condition where we
> have shared a model between the calling page and the ModalWindow. We
> have an autocomplete textfield with an onblur handler attached. This
> onblur handler is triggered when the modal window is shown resulting
> in two parallel Ajax requests to the server. This causes the shared
> model to be attached and detached at the same time, resulting in
> rather funky behavior.
> I know that one solution is to not share the model between the
> ModalWindow and the calling page. But we are looking for alternative
> (more general) solutions.
> Options we thought of:
>  - would locking the session for page directed requests implementable
> (i.e. let resource requests through the barrier, but not both requests
> to the calling page and the modalwindow page)
>  - would it work to set a client side flag when the ModalWindow is
> requested, that disables wicket-ajax for the current window to happen
> (preventing the onblur to trigger Ajax), and is reset when the
> ModalWindow is rendering in the client?
>  - render the modalwindow page in the current pagemap instead of a new
> one (would make refresh behavior pretty weird I think)
> Any other suggestions?
> Martijn
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org

To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org

View raw message