Re: You backtrack too far problem. Analyzing ERXRequests...
Re: You backtrack too far problem. Analyzing ERXRequests...
- Subject: Re: You backtrack too far problem. Analyzing ERXRequests...
- From: Ramsey Lee Gurley <email@hidden>
- Date: Fri, 18 Dec 2009 08:22:36 -0500
On Dec 18, 2009, at 3:18 AM, Gustavo Pizano wrote:
> Then I click an AjaxSubmitButton which will update a "dummy AUC", this one will onRefreshComplete update a AUC inside the Second AjaxSelectionList with a unique ID generated in the server side,
Hmmm... I'm not sure this is your problem Gustavo, but it might be worth checking. Set breakpoints on your generated update container id methods server side. Log them to the console if there are a lot. Make sure your unique ids are really unique! (^_^) I recently had a problem where there were two update containers inside an update container, and the first was in a WOConditional. Something like
<AUC1>
<WOCond>
<AUC2/>
</WOCond>
<AUC3/>
</AUC1>
The problem I encountered was that my AUC2 was not being shown the first time, and the ID generated and cached using ERXStringUtilities.safeId...(context().elementID()) for AUC3 was the SAME as the value generated when AUC2 appeared! My AUC2 had an ajax trigger in it to update AUC3 on refresh. Since they both had the same ID, that caused AUC2 to spin out into an infinite loop, updating itself instead. I've never seen a backtrack cache error as a result of an Ajax update though, so this may not be your problem. It took me forever to find this problem. Be persistent. You will find your problem too!
Ramsey
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden