Re: D2W + custom EOEditingContext subclass [SOLVED]
Re: D2W + custom EOEditingContext subclass [SOLVED]
- Subject: Re: D2W + custom EOEditingContext subclass [SOLVED]
- From: Sam Barnum <email@hidden>
- Date: Thu, 27 Sep 2007 10:08:09 -0700
OK, I've solved this, pretty much
It turns out that after appending my own site-specific qualifier, I
was setting a hint in the fetch spec that the qualifier had been
appended, to prevent appending it multiple times (because that was
happening in some named fetch specs). However, I guess the
D2WQueryPage reuses the fetch specification object, but sets the
query on there. So my flag was still set, but the query had been
replaced.
On Sep 26, 2007, at 5:25 AM, Sam Barnum wrote:
I'm using a custom EOEditingContext subclass to auto-restrict
qualifiers (thanks to everyone who had suggestions on that)
To do this, I need to ensure that all DB access is done through my
EOEditingContext subclass (EGEditingContext).
I'm also using D2W.
The D2W class instantiates an editing context in a few places, and
I've written my own factory to take care of these
(editPageForNewObjectWithEntityNamed and
editPageForNewObjectWithConfigurationNamed). However, my client
uncovered some odd behavior in the query all page involving the
back arrow that was instantiating a regular EC.
If I want to ensure that only my custom EC subclass is used in D2W,
what other places to I need to attend to? Is there a definitive list?
I've added a check in awakeFromInsertion() to throw an exception if
my objects are instantiated in a regular EC.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40360works.com
This email sent to email@hidden
_______________________________________________
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