Thanks for the pointer about savePage(). As a result I've now
discovered that my editObject page (reached from a WOHyperlink in a
WODisplayGroup) is not calling savePage() for some reason. The rest of
the session life-cycle appears as normal.
viz: DisplayGroup Page session activity:
awake()
invokeAction()
appendToResponse()
savePage()
sleep()
then for the next page, editObject page session activity:
awake()
invokeAction()
appendToResponse()
sleep()
so my sessionID propagates quite happily and all my successive
contextIDs look OK and everything *appears* normal, only the page
cache is, I guess, missing a page. As you can imagine I have no idea
why this happens (a bug?).
However, it can be fixed by calling session().savePage(this) in the
constructor of the editObject page, and *also* in my WOSubmit action
method (and indeed in every Component-based exit of that page) as the
constructor is not called on successive calls to the page, but the
page must be cached at every successive call to the page.
I realise that I might be adding the odd unnecessary page to the
cache, but it's a small price to pay to get it working again, unless
anyone sees any problems with that approach?
.neilmac
PS <side benefit>I'm keeping going with the Wonder-ised version of my
app. A whole new world to explore...</side benefit>
On 20 Dec 2007, at 02:46, Chuck Hill wrote:
I'm having trouble with DisplayGroups and a "backtracking too far"
error -- without pressing the Back button on my browser, i.e. on a
'forward, progressive' link/action
I have a DisplayGroup within a WOComponentContent template. The
DisplayGroup shows me a batch of entries (using a WORepetition),
which are WOHyperlinks to another Component which is designed to
edit the particular item. That bit works fine. Once I try to update
the edited entry (submit button returning 'null'), or click on any
other WO-managed link, I get a "You have backtracked too far, The
application backtracking limit of XX has been exceeded". I get this
without even touching the back button! No errors sent to the console.
From what I've gleaned on Google, I sense "trouble" with
WODisplayGroups and backtracking. But in all the examples I've
found they involve pressing the "back" button in order to create a
problem.
My efforts:
I've tried "Wonder-ising" my simple WebApp, using
ERXBatchingDisplayGroup, but the result is the same.
I've increased the page cache limit to, say, 300 and still the
result is the same. My database result set is only 30 or so rows. I
suspect that the problem is nothing to do with the value of of the
page cache, but perhaps something else is throwing an error which
happens to be caught by the backtracking error mechanism
(handlePageRestorationError, I think)
I think you are correct WRT to the page cache. I'd guess something
along the lines of the session missing on the URL. If WO creates a
new session and then tries to use a component action URL you can get
this error. I'd also override and add logging to savePage() in
session to ensure that something (java script, bad HTML) is not
creating a flurry of bad requests to the app and thus knocking the
page out of the cache.
I'd think that investigation along those lines, rather than the
display group, is more likely to lead to your answer.
Chuck
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
