Re: DisplayGroups and Backtracking Too Far [Fixed]
Re: DisplayGroups and Backtracking Too Far [Fixed]
- Subject: Re: DisplayGroups and Backtracking Too Far [Fixed]
- From: Chuck Hill <email@hidden>
- Date: Thu, 20 Dec 2007 19:35:47 -0800
On Dec 20, 2007, at 4:05 PM, Neil MacLennan wrote:
Yes, yes, yes I know it wasn't a real "fix" by calling savePage()
from somewhere else. I was trying to appease my guilt by posting
and hoping for a comforting, "there, there young man, it'll be OK.
Don't worry about it. Nobody got hurt, let's just move on".
Regretfully, no such comfort was found! ;-)
Grin. We are not much for sugar coating things.
After writing almost 400 words of an e-mail explaining step-by-step
my application to you all, and working through it diligently, I
came across my schoolboy error.
I have no idea why, when I move from the WODisplayGroup page to the
EditObject page, I used an action method of the form:
public EditOrder editBooking() {
EditOrder nextPage = new EditOrder(context());
return nextPage;
}
instead of,
public EditOrder editBooking() {
EditOrder nextPage = (EditOrder)pageWithName("EditOrder");
return nextPage;
}
That is an interesting side effect of doing that. I have captured
this in the wiki:
http://wiki.objectstyle.org/confluence/display/WO/Web+Applications-
Development-Common+Pitfalls+and+Troubleshooting
I *always* use "pageWithName". I can only imagine that I
copied'n'pasted it from a web page when I was researching
programatically creating a WODisplayGroup or something (the 'blame
someone else excuse(tm)').
Anyway, thanks to those who helped. Sorry for taking up your time,
and I'm eating humble pie for suggesting that it might have been
the mighty WO at fault, and not me.
Thanks for letting us know. Maybe that bit in the Wiki will save
someone else some pain.
<side benefit>I understand a lot more about the Component lifecycle
after this little 'exercise'</side benefit>
:-) Well, it was not a total loss then.
Chuck
On 20 Dec 2007, at 21:38, Chuck Hill 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?
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
--
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