Re: make that dataSource (was Re: an interesting delegate design issue raised by IB...)
Re: make that dataSource (was Re: an interesting delegate design issue raised by IB...)
- Subject: Re: make that dataSource (was Re: an interesting delegate design issue raised by IB...)
- From: Enrique Zamudio <email@hidden>
- Date: Wed, 12 Sep 2001 14:32:33 -0500
- Organization: Nasoft
>
Like I said in my original post, I realize this is a case of wanting my cake and eating it too. I
>
would like one class where to start using it, a user/developer could just drag one off the palette
>
onto a window, and then drag images on to it, using it just like a NSImageView, but being able to
>
leverage the additional power of my class (zooming, fullscreen, compositing, etc.).
>
>
After they've become comfortable with it and use it in many places, and they come up with a more
>
sophisticated use for it that involves sharing image data among other views, I'd like them to just
>
be able to use that class and wire it up to a data source, and voila - have it "just work".
>
>
I'd rather they didn't have to actually understand notifications, delegation, data sources, etc.
>
just to get started.
If you think about this in a different way... developers will have to understand delegation, data
source and notifications at some point, unless they're always doing very simple stuff.
So you might be helping someone by making them learn this sooner... once they learn delegation/data
sources/notifications by using your objects, they'll know how to use them with other objects, since the
design principles are the same.
>
>
<mild rant>
>
>
Trying to introduce people to Cocoa, this is a big problem I see: NEXTSTEP/Openstep/Cocoa was/is the
>
best GUI application framework I've ever seen; arguably it's the best one ever written. The major
>
impediment to an explosion of amazing apps is that you have to be very smart, and have access to
>
other smart people and ask them the right questions in the right order to get up the hill such that
>
you're able to really leverage just how powerful and well designed Cocoa is. I was there with
>
NEXTSTEP, I sat out the Openstep stuff, but I'd like to get back in there for Cocoa, and am
>
interested in figuring out how to get more people to come along with me.
I've also been using this stuff since it was NEXTSTEP (who remembers the NX classes that came with the
first appkit? when you had to use "free" and there was no retain/release infrastructure...)
I think there has been a great advance since then, and I also think this is one of the best frameworks
ever (come on, IB has barely changed since the NEXTSTEP days, and it has only been for the better).
>
One of the points of putting classes on IB palettes is so that people can use them with a minimum of
>
understanding - they should be able to drag an instance off a palette and immediately use it - not
>
have to read header files, not have to read README files, not have to be a terribly sophisticated IB
>
user. Ideally, though, once they do become more sophisticated, and read the README (or eventually
>
the header file :-)) they shouldn't have to switch over to a whole new set of objects to utilize
>
these ideas - they should ramp smoothly up to the next level.
>
Agreed. That's how I started learning to use the AppKit, by using IB and connecting objects and then
finding out how to interact with them by creating my own classes and such.
Perhaps your "invisible" internal data source isn't such a bad idea... as long as there is a detailed
explanation of its reason d'etre and there is a way to implement a different one that could be more
sophisticated (fetching images from a database or the web or whatever).
eZL