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