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
