Re: Nested Editing Contexts
Re: Nested Editing Contexts
- Subject: Re: Nested Editing Contexts
- From: Chuck Hill <email@hidden>
- Date: Wed, 30 May 2007 15:15:51 -0700
On May 30, 2007, at 12:57 PM, Steven Mark McCraw wrote:
I definitely don't want to strike up a semantic argument on a list,
but just to clarify: I think it's weak due to documentation and
implementation. I can fully appreciate the complexity of the
problem set EOF is solving. Tracking state is a bear, and I can
appreciate the necessity of having to constrain programming
language rules for a particular set of objects in an unintuitive
way. But if the framework is such that failure to comply to those
rules leads to untraceable, mysterious, unexpected behavior, I
think the vendor should:
A) Clearly document the issue from the outset of the product.
Without an active third party community that enlightened these
issues, I feel sure I would have never been aware of them, and
probably would have switched development platforms in frustration
by now.
Cough. Cough.
http://developer.apple.com/documentation/WebObjects/
Enterprise_Objects/EnterpriseObjects/chapter_3_section_13.html#//
apple_ref/doc/uid/TP30001011-DontLinkChapterID_8-TPXREF146
And I quote, "Note that immediately after the enterprise object is
created, it is inserted into an editing context. As a cardinal rule,
all enterprise objects reside in an editing context. This is
necessary in order for enterprise objects to send and receive the
notifications necessary for change tracking and other mechanisms
within Enterprise Objects. So, for every enterprise object you
create, you must immediately insert it into an editing context."
http://developer.apple.com/documentation/WebObjects/
Enterprise_Objects/BusinessLogic/chapter_4_section_3.html#//apple_ref/
doc/uid/TP30001011-DontLinkChapterID_3-TPXREF140
"You may wonder why it’s not recommended to initialize an enterprise
object’s values in an object’s constructor. An enterprise object’s
constructor represents the earliest state in the life of a particular
object. The state of an enterprise object at the point of
construction is not complete; the object is not fully initialized. It
may not yet have been inserted into an editing context and it might
not even have been assigned a global ID. You don’t ever want to
manipulate an enterprise object that isn’t in an editing context or
that doesn’t have a global ID."
B) Programmatically constrain programmers to follow those rules.
Since changing the state of an object is so catastrophic if the
object is not in the pool that enables it to be tracked, why not
throw an exception when that condition is encountered, rather than
just letting the programmer proceed and wander into the terrible
limbo of a hosed database context and all sorts of strange,
untraceable and difficult to reproduce behavior?
I have often wondered that. Now you have gone and provoked me. I
will file a bug report. You _can_ do this yourself by adding this to
your base EO class:
public void willRead() {
if (editingContext() == null) {
throw new IllegalStateException("Access of instance of " +
entityName() + " that has not been inserted into an EOEditingContext
or whose EOEditingContext has been disposed");
}
super.willRead();
}
I think either one of those things would have saved lots of grief
over the years for developers. I know it would have for me. At
any rate, it's just my opinion, and it's so irrelevant anyway that
I almost deleted this email without sending it to the list, but my
fragile ego prevailed. I promise this will be the last one :)
Not if you reply to this one! Grin.
Chuck
On May 30, 2007, at 3:21 PM, Mike Schrag wrote:
You have stumbled upon what I believe to be one of the biggest
weaknesses in EOF, and the solutions are (again, in my opinion)
terrible.
I don't really see this as a big weakness of EOF ... It has to be
able to track changes, and without an editing context, it's not in
a "transaction", and therefore you can't do it. You can usually
get away with this if you're setting non-relationship attributes,
but especially when it comes to relationships to other objects,
this just can't fly.
I put my "constructor" eogenerator templates up on the wikibook
page months ago -- it autogenerates YourEntity.createYourEntity
(...) with the attributes based on all required attributes and all
required relationships. This gives you essentially exactly what
you would expect a constructor to have, but more like a factory
sort of pattern than a traditional constructor.
ms
_______________________________________________
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