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 window". (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. :-) Kindly, Per On Fri, Jul 3, 2009 at 3:11 PM, Martijn Dashorst<[email protected]> 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: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
