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
>>
>>
>
