Re: The Problems with NSController
Re: The Problems with NSController
- Subject: Re: The Problems with NSController
- From: Hsu <email@hidden>
- Date: Sun, 26 Oct 2003 23:54:53 -0800
On Oct 26, 2003, at 10:22 PM, Jonathan Hendry wrote:
This is true, but it may be because of time-to-market concerns, or
concerns about overwhelming (new) users with more possibilitiies than
many of them need? EOF had a pretty good idea where they were going
and what their target audience was. It could be that Apple put out
the basic structure, and are looking to see where the developers want
it to go before adding the code. Once new API or behavior is added to
the 'Kits, it's mighty hard to remove, so I can see Apple being very
careful about it. Backward compatibility is much more important to
Apple than it was to NeXT (for obvious reasons, I think).
I don't think that's true about NeXT. After all, EOF and Foundation
were
initially released as an optional add-on to NeXTSTEP 3.2. They didn't
add them during
an epochal compatibility break like 10.3. EOF and Foundation added
functionality
without requiring wholesale replacement of the AppKit, or breaking 3.x
programs.
The NeXT market was considerably smaller, and consisted (in large part)
of vertical market applications. This lends itself to maintaining
source, but not binary compatibility. Current MacOS can't really do
that (people already get pretty upset at the amount of breakage).
It's true that it's hard to remove API. Which makes me wonder even
more why the
NSController is the way it is.
What would need to change about the NSController API to fix it (in
contrast to adding API or changing behavior)?
Of course, the objects that EOF managed were controlled by the
EOModel, which provided a great deal of meta-information about the
objects (such as which attributes are important, etc). I think
perhaps requiring an EOModel for a basic controller object is a bit
more complex than strictly necessary.
Are you thinking of database undo/rollback? I can't see how the Model
has anything to do with
Appkit-level Undo. Appkit-level undo applies to all attributes, even
ones that are
not important in the database schema. The Model would influence
rollback behavior
and referential integrity, which aren't really at issue here.
Do you always want every single attribute change to be registered with
the Undo manager, all the time? Even so, it seems like this sort of
automatic undo management could be added in a future release without
any serious issues, implying that it's not really a fundamental
architectural flaw in the Bindings.
I'd expect AppKit/Foundation/CoreFoundation to be rife with unsavory
hacks to the runtime system. That's the point of AppKit/Foundation
now, really - do all the groddy stuff so we don't have to :)
In any case, I kind of like the Bindings way better - no more doing
the work by hand (or doing it through EOModeler, which is again
overkill for many many use cases). And it's overrideable if you so
desire.
EOModeler was nice because it generated code. ;^)
And you could drag things into IB,
so IB would know about attributes 'n stuff, automagically.
But isn't this a function of having designed your data model in
EOModeler? Still seems like there is some disconnect between Data Model
and Controller. They seem different to me - the Bindings are designed
to address the "Controller" part of MVC (more specifically the VC
part), not the "Model" part.
We need NSModeler, I think. Forget about the SQL stuff, just a nice
GUI tool
for creating skeleton model classes, which would generate source and be
integrated with IB.
Perhaps they will come later. Their lack now doesn't seem like a
sweeping architectural flaw in the Bindings, just an area that the
Bindings don't address. The Bindings bring automatic change management
without the need for code generation (quite nice) and a strong
separation from the concept of data persistance (also quite nice).
(Note: Not to say data persistance wouldn't be welcomed with open arms,
but at that point you start getting into NSModeler territory).
don't really agree. I think the Bindings were a very focused addition
to Cocoa. I understand your frustration that it is so _very_ focused
(given its EOF heritage) but at the same time, I think it's more
useful to judge it by what it brings rather than what it _could_ have
brought if Apple had imported the EOF stack wholesale.
They're definitely an improvement, and it sucks to complain about
something people have been asking for, but I have to wonder about why
they seemingly threw out so much. It's
almost like they hadn't used EOF. (I haven't used Java EOF yet. Is
NSController like
that at all?)
I think "they" have used EOF, and are cognizant of it's shortcomings in
a Desktop sense. EOF is a fairly dense framework for data object
management and persistance. It was really cool if that was what you
were doing, but kind of annoying if you only wanted little bits of it.
Again, I think the idea of breaking up EOF, to make the individual
parts easier to use by themselves is probably the goal, and a laudable
one.
Java EOF is pretty similar to Obj EOF, given the difference in
languages.
The Bindings seem aimed squarely at the desktop market. Looking at
them with Enterprise colored glasses on, I can certainly say they are
poorly designed, but I have a hard time saying that when looking at
them with Desktop-app colored glasses on. From that point of view,
they seem quite useful (not the garden of eden for sure - something
_like_ EOF would be a godsend), but certainly not the train wreck you
paint them to be.
I'm not entirely sure what "Enterprise" has to do with it, since the
database functionality isn't really at issue.
It is, only because Aaron's initial post pointed out the lack of SQL
generation as a "basic design flaw".
Everything in EOF at the UI level would be quite at home
in 'desktop' applications. And you never know when a customer is going
to try
to use your 'desktop' framework to do 'enterprise' work.
And in future releases, that may be easier and easier to do. Think of
it this way: Apple decided, for whatever reason, that the existing ObjC
EOF code was insufficient for their needs (too hard to use, too many
new idioms to throw at developers all at once, too much dependance on
the aging EOModeler, whatever). I'd rather they release what they have
incrementally, so we can use it, than wait years for everything to fall
into place before it sees the light of day.
I agree with you and Aaron that the Bindings are missing many things
that EOF had, and those things should be reintroduced. However, my bone
of contention is that I don't see them as "basic design flaws" but
rather as a deliberate simplification. In particular, I believe that
the simplification is done in such a way that those missing features
can be introduced at a later point with little difficulty (on the part
of the end user developer).
Seems to me that the NSController layer is to EOF's UI layer as DBKit
was to EOF.
DBKit was before my time. Vague poking around seems to imply that the
change from DBKit to EOF was driven in large part by the needs of
WebObjects. (Wild speculation on my part there).
Karl
--
We, the unwilling,
led by the unknowing,
have been doing the impossible
for the ungrateful.
We've done so much for so long,
we are now qualified to everything
with nothing.
Homepage:
http://homepage.mac.com/khsu/index.html
_______________________________________________
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.