• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: EditingContext problem
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: EditingContext problem


  • Subject: Re: EditingContext problem
  • From: Chuck Hill <email@hidden>
  • Date: Thu, 22 Apr 2004 13:30:38 -0700

An application with multiple EOF stacks will have multiple EOModelGroups. Thus in order to determine the EOEntity instance (different in different groups) an EC is needed to determine which stack to look in.


Chuck

On Apr 22, 2004, at 11:22 AM, Jonathan Rochkind wrote:

At 10:43 AM -0700 4/22/04, Chuck Hill wrote:
- It's API is polluted by its historic background. Many of the methods taking an EOEditingContext for argument could do without.

Which methods are you thinking of? The reason that they take an EOEditingContext is to handle the case where there are multiple EOF stacks.

Hmm, how about entityForClass? entityForObject? qualifierForEnterpriseObject? But maybe those can depend on EOF stack too. But my impression is someone as a habit just added an EC argument to everything in EOUtilities to avoid thinking about whether it was really neccesary. But you're right it is neccesary for most of the stuff in there.


As far as pollution between EOAccess and EOControl---I don't see how it can be avoided. There is plenty of genuinely useful stuff in EOUtilities, and for much of it, I don't see how it could be accomplished _without_ involving both EOAccess and EOControl. A lot of the stuff in EOUtilities I see an an answer to the problem: "Gee, I want to do something that I can only do with eoaccess. But it takes way too much code to do it, and for 99% of the time this will be the same code, taking EOControl objects as arguments and working from there to get to the EOAccess." So EOUtilities does that for you, taking the eocontrol objects and doing the useful eoaccess layer thing for you.

I suppose theoretically the design of EOF could be improved so some of these things didn't require eoaccess involvement, you could do it solely with eocontrol. But as it is, that's not the case. Sometimes you need to deal with eoaccess, and dealing with eoaccess is a pain---pain that EOUtilities thankfully eliminates for many common tasks.

--Jonathan


Chuck
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.


References: 
 >Re: EditingContext problem (From: Chuck Hill <email@hidden>)
 >Re: EditingContext problem (From: Jonathan Rochkind <email@hidden>)

  • Prev by Date: Re: OpenSource replace EOModler
  • Next by Date: Re: Using third-party jars on OS X
  • Previous by thread: Re: EditingContext problem
  • Next by thread: RE: EditingContext problem
  • Index(es):
    • Date
    • Thread