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
