@Martijn, did came up with a solution to this. I'll be glad to hear it. Thanks
Per Lundholm wrote: > > Oh, that is a good one. > > You could make it a modal window. After a while that window (I assume) > would get to contain more and more settings. Then all of a sudden, the > last setting you added will really make statistics take a very long > time. Since the user probably can't foresee that, you wish to confirm > that the user have understood the implications. So you need a modal > window that ... oops ... you are already in a modal window. > > The first thing is to think about as an alternative is to start with > direct manipulation. Is there any way you could change the settings > right when you are looking at the statistics? Typical example is the > familiar "click on column heading to sort table on contents of that > column". Consider drag-n-drop objects if that is natural. > > Second is to have the modal window inline on the page in panel. After > all, selected settings and the result in the same window feels better > than switching to another window, modal or not and then back. But > there may not be room for that. Can you split the settings in groups > to inline on several places on the page? > > Next thing to consider is to have it on another page and here comes > another concern in regarding the concept of settings, life cycle. Do > all settings have the same settings? Which are per request, per > session, per user, per application? Side point? Well, it sure controls > presentation since settings with different life cycle should not be > presented together. > > If the selection of statistics is a very separate activity, maybe it > should be on separate page before the page that presents the result? > Changing settings would be reached by pressing the back button. > > As you understand, I am guessing here as I have not much to go on. But > these are my thoughts. Try direct manipulation, keep selections > visible all the time or resort to a separate page. Save modal windows > for that yes/no confirmation. You will need it eventually. > > Kindly, > Per > > > On Sat, Jul 4, 2009 at 2:13 PM, Eyal Golan<egola...@gmail.com> wrote: >> 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 >> egola...@gmail.com >> >> 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 <per.lundh...@gmail.com> >> 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<martijn.dasho...@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-unsubscr...@wicket.apache.org >>> > For additional commands, e-mail: users-h...@wicket.apache.org >>> > >>> > >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > > -- View this message in context: http://www.nabble.com/Detaching-and-ModalWindow-causes-race-condition-tp24322954p24397285.html Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
