Per, I see what you're saying and I have a question. How would you implement (UI concern) a setting page? What I mean is, suppose I have a page that shows some statistics. The statistics can be set by the user. We implemented a link / button that opens up a modal window to select the statistics. How would you do it?
Eyal Golan [email protected] Visit: http://jvdrums.sourceforge.net/ LinkedIn: http://www.linkedin.com/in/egolan74 P Save a tree. Please don't print this e-mail unless it's really necessary On Sat, Jul 4, 2009 at 1:40 PM, Per Lundholm <[email protected]> wrote: > 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] > >
