Thanks for the info! I don't think that's the culprit here, although I'll keep in mind that multiple requests might not arrive in the order sent.
On Fri, Feb 25, 2011 at 11:04 AM, Rich M <rich...@moremagic.com> wrote: > I can't say with any certainty this is your problem, but the one time I was > having issues with an AJAX request being dumped and never showing up server > side there was a race condition. I had it listening to the click event of a > submit button, and on slower connections the form submit would beat out the > AJAX request to the server. In your case I could see the Periodic update > (assuming its on the same page) creating some sort of race condition. Worth > considering if so. > > Here is the link to the thread on this list so you can compare and see if > your code is similar: http://tapestry.markmail.org/thread/6nlztv5dlv4pix77 > > Regards, > Rich > > > On 02/25/2011 10:35 AM, Bryan Lewis wrote: > >> To follow up... moving the first select out of the zone didn't help. I >> didn't see how it would, was grasping at straws. >> >> I finally avoided the problem by getting rid of the chained selects. I >> went >> back to our older component that does the chaining with simple javascript >> (stuffing all the possible selection lists into the html which works okay >> if >> they're not huge), so there's no ajax request on the first select. The >> second select does an onchange form submit. Crude and a bit slower but it >> works. >> >> In other words it stumped me. Maybe some day someone else will see this >> posting and have an insight. >> >> >> On Fri, Feb 25, 2011 at 10:24 AM, Bryan Lewis<jbryanle...@gmail.com> >> wrote: >> >> Nope. In the failing cases, the ajax request did not arrive at my >>> AppModule's request filter. That's why the Select's onValueChanged() >>> isn't >>> getting called. I don't think it's a case of Tapestry dropping the >>> request >>> after it gets it. >>> >>> >>> >>> On Fri, Feb 25, 2011 at 6:41 AM, Ulrich Stärk<u...@spielviel.de> wrote: >>> >>> Can you see the request hitting the server after the first zone's value >>>> is >>>> changed? >>>> >>>> Uli >>>> >>>> On 24.02.2011 23:43, Bryan Lewis wrote: >>>> >>>>> I've been trying to figure out a weird bug today, and before I lose the >>>>> night over it I thought I'd ask the list. I'm using the cool new >>>>> >>>> "chained >>>> >>>>> select" feature. One Select has a zone, and triggers an >>>>> >>>> onValueChanged() >>>> >>>>> method that affects another Select. It works fine on my machine and >>>>> >>>> when >>>> >>>>> most users try it. When the first selection changes the server gets >>>>> the >>>>> method call and the zone updates, no problem. >>>>> >>>>> We have a few users in a remote office who access the application >>>>> >>>> through a >>>> >>>>> slightly slow connection to a Citrix server. That is, the browser is >>>>> actually running here (in the same network as the app server) and the >>>>> >>>> user >>>> >>>>> receives only screen updates. Occasionally these users will see that >>>>> >>>> the >>>> >>>>> chained selects don't work at all. I've debugged it a little (kinda >>>>> difficult since I can't make it happen locally) and the first Select's >>>>> method call doesn't happen. I don't think it's only a case of slowness >>>>> >>>> -- I >>>> >>>>> waited about ten seconds. >>>>> >>>>> Does this ring any bells? I can't see how the Citrix factor or the >>>>> connection speed would have any effect. The app server and browser are >>>>> >>>> in >>>> >>>>> the same network. Other requests are working fine; the app has been >>>>> >>>> running >>>> >>>>> almost a year. I have a periodic-update ajax request that successfully >>>>> makes it to the server for the same user. >>>>> >>>>> So maybe I'm using the new feature incorrectly. >>>>> >>>>> .tml: >>>>> >>>>> <t:zone t:id="recipientZone" update="show"> >>>>> <br/> >>>>> <t:label for="carrierSelect">Recipients</t:label> >>>>> <table style="margin-left:124px;"> >>>>> <tr> >>>>> <td> >>>>> <t:select t:id="carrierSelect" >>>>> model="carrierModel" >>>>> value="selectedCarrier" >>>>> blankLabel="literal:Select a carrier first" >>>>> zone="recipientZone" >>>>> style="width:180px;"/> >>>>> </td> >>>>> <td> >>>>> <t:select t:id="recipientSelect" >>>>> model="recipientModel" >>>>> value="selectedRecipient" >>>>> style="width:360px;"/> >>>>> </td> >>>>> </tr> >>>>> </table> >>>>> </t:zone> >>>>> >>>>> >>>>> .java: >>>>> >>>>> private final SelectModel carrierModel = new AbstractSelectModel() >>>>> { >>>>> // Omitting null-returning getOptionGroups() for simplicity >>>>> >>>>> public List<OptionModel> getOptions() >>>>> { >>>>> List<Company> carriers = getModel().getCarriers(); // >>>>> >>>> sorted by >>>> >>>>> name >>>>> List<OptionModel> options = >>>>> CollFactory.newList(carriers.size()); >>>>> for (Company carrier : carriers) { >>>>> options.add(new >>>>> OptionModelImpl(carrier.getCarrierShortName(), carrier)); >>>>> } >>>>> return options; >>>>> } >>>>> }; >>>>> public SelectModel getCarrierModel() >>>>> { >>>>> return carrierModel; >>>>> } >>>>> >>>>> public Object onValueChangedFromCarrierSelect(Company carrier) >>>>> { >>>>> debug("-- onValueChangedFromCarrierSelect " + >>>>> carrier.getCarrierShortName()); >>>>> selectedCarrier = carrier; >>>>> return recipientZone.getBody(); >>>>> } >>>>> >>>>> >>>>> To be clear: In the real app, the recipientSelect also has a zone >>>>> >>>> parameter >>>> >>>>> to update a third list. I omitted it here because the bug happens >>>>> >>>> before >>>> >>>>> that. >>>>> >>>>> The only thing I can see that I'm doing different from the documented >>>>> example is, my selects are in the same zone. I'll try splitting them >>>>> up >>>>> >>>> and >>>> >>>>> using a MultiZoneUpdate or some such. >>>>> >>>>> Thanks for any ideas. >>>>> >>>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>>> For additional commands, e-mail: users-h...@tapestry.apache.org >>>> >>>> >>>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
