Re: EOF - was (Cocoa Books (was New to Cocoa) )
Re: EOF - was (Cocoa Books (was New to Cocoa) )
- Subject: Re: EOF - was (Cocoa Books (was New to Cocoa) )
- From: Don Yacktman <email@hidden>
- Date: Mon, 14 Oct 2002 17:09:44 -0600
On Monday, October 14, 2002, at 02:57 PM, Scott Anguish wrote:
On Monday, October 14, 2002, at 03:33 PM, Jeff LaMarche wrote:
I'm guessing that this is not perceived as a gap with much profit
potential because EOF is, by its nature, primarily a tool for
developing persistent, large-scale (and scalable) applications.
This is a terrible misnomer
Absolutely!
EOF is an outstanding piece of technology. WebObjects would probably
not have attained the current level of acceptance that it has without
it. But did you know that EOF also has a number of classes that allow
you to trivially write database applications with Cocoa GUI frontends?
It is a fantastic system, and very useful for writing back end
applications for WebObjects.
Its usefulness doesn't end there, though. Unfortunately most people are
unfamiliar with the details of the frameworks and thus miss its full
potential. This is because it has a "marketing" name meant to evoke a
particular application segment (Enterprise) as opposed to the other
frameworks which have names more descriptive of their function (such as
"AppKit" and "Foundation"). A much better name would be "Persistent
Objects Framework". Objects created by the EOF framework often have
custom functionality (commonly referred to as business logic) as part
of their implementation.
Another part of the misconception is that EOF is only as a way of
getting data into and out of relational databases. While it does do
this, there is nothing about EOF that precludes other storage
mechanisms. Apple includes two sample EOAdaptors that do just that: one
that allows access to flatfiles and another that allows queries on LDAP
directories. Other interesting possibilities include: accessing the
application defaults database, NetInfo, IMAP mailboxes or Usenet
servers.
And I'd add that you could call EOInterface "CocoaControllerKit" if you
wanted to -- it can handle a lot of the boring glue we currently have to
write behind our GUIs...something that EVERY Cocoa developer could
benefit from if they'd only let us have an Objective-C EOF again...
What too few Cocoa developers realize is that the EOF technology is
something that every single Cocoa developer could benefit from. The
name assigned to it by NeXT's marketing, that it is now saddled with, is
terribly misleading. The name makes people dismiss it as "doesn't apply
to me" before they ever figure out what it *really* is! If every Cocoa
developer knew what they could have had and currently don't have, I
think every single one would be trying to beat Apple over the head with
a clue by four by now...
EOF is a *lot* of things, and doing "enterprise" objects is only one of
the very few ways it can be beneficial to us. Scott listed a lot of
interesting things you can do with it. These are broadly applicable to
most Cocoa developers. For example, what developer wouldn't like to be
able to create a fully functional Preferences panel with no code and
just a bit if twiddling in IB? EOF could do that. Instead, a lot of
people write a lot of code just to get the prefs UI working right. It's
a travesty.
--
Later,
Don Yacktman
email@hidden
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.