Re: Nested Editing Contexts
Re: Nested Editing Contexts
- Subject: Re: Nested Editing Contexts
- From: Steven Mark McCraw <email@hidden>
- Date: Wed, 30 May 2007 15:57:09 -0400
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.
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 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 :)
Mark
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:
This email sent to email@hidden