@Martijn, did you came up with a solution to this. I'll be glad to hear it.
Juan Carlos Garcia M. wrote: > > @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<[email protected]> 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 >>> [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] >>>> >>>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >> > > -- View this message in context: http://www.nabble.com/Detaching-and-ModalWindow-causes-race-condition-tp24322954p24397295.html Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
