Re: DisplayGroups and Backtracking Too Far [working]
Re: DisplayGroups and Backtracking Too Far [working]
- Subject: Re: DisplayGroups and Backtracking Too Far [working]
- From: Chuck Hill <email@hidden>
- Date: Thu, 20 Dec 2007 13:38:52 -0800
On Dec 20, 2007, at 7:35 AM, Neil MacLennan wrote:
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.
I am not sure why that would be. Probably overriding some WO methods
and not calling super. Try adding this to savePage():
NSLog.out.appendln(new RuntimeException("savePage() backtrace"));
Take a look at the backtrace from a page where this gets called.
Does the editObject page override any methods in that trace? Do they
call super?
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?).
A bug in your code. :-) The only other thing I can think of is that
you are doing something Ajaxy and using Wonder and Wonder incorrectly
thinks this is an Ajax call. Those go into a different cache.
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?
That is a terrible way to fix this. You are just begging for, nay
demanding!, severe troubles later. Find the problem and fix it now
or you will regret it later.
Chuck
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@hidden)
Help/Unsubscribe/Update your Subscription:
40global-village.net
This email sent to email@hidden
--
Practical WebObjects - for developers who want to increase their
overall knowledge of WebObjects or who are trying to solve specific
problems.
http://www.global-village.net/products/practical_webobjects
_______________________________________________
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