You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Martijn Dashorst <ma...@gmail.com> on 2009/07/03 15:11:58 UTC
Detaching and ModalWindow causes race condition
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
Re: Detaching and ModalWindow causes race condition
Posted by Johan Compagner <jc...@gmail.com>.
Dont share models between pages if possible.
This is also a problem if 1 or both of them is serialized and then
read back in, then you suddenly have 2 instances because pages are not
serialized as one thing.
On 03/07/2009, Martijn Dashorst <ma...@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
Re: Detaching and ModalWindow causes race condition
Posted by "Juan Carlos Garcia M." <jc...@gmail.com>.
@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<eg...@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
>>> egolan74@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 <pe...@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<ma...@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
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>>
>
>
--
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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Detaching and ModalWindow causes race condition
Posted by "Juan Carlos Garcia M." <jc...@gmail.com>.
@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<eg...@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
>> egolan74@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 <pe...@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<ma...@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
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Detaching and ModalWindow causes race condition
Posted by Per Lundholm <pe...@gmail.com>.
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<eg...@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
> egolan74@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 <pe...@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<ma...@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
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Detaching and ModalWindow causes race condition
Posted by Eyal Golan <eg...@gmail.com>.
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
egolan74@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 <pe...@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<ma...@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
>
>
Re: Detaching and ModalWindow causes race condition
Posted by Per Lundholm <pe...@gmail.com>.
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<ma...@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