Re: Cocoa patterns?
Re: Cocoa patterns?
- Subject: Re: Cocoa patterns?
- From: "l.m.orchard" <email@hidden>
- Date: Mon, 27 Aug 2001 08:13:18 -0400
On Sunday, August 26, 2001, at 11:35 PM, brian hook <email@hidden>
wrote:
At 12:59 AM 8/27/01 +0200, Georg Tuparev wrote:
- Do not start with a big project. Start with something smaller. A
concrete document editor would be probably a good place. Wait until you
get the "aha" feeling.
This makes eminent sense.
I just had this happen to me with force this weekend. I started a week
or so ago playing with NSOutlineView and the DragNDropExample, moved
onto making the example into a document-based app, moved on from there
to playing with NSUn/Archiver and coding to save files, learned more
about WindowControllers and started making tool and info windows...
After awhile, everything I wanted to do made perfect sense and I found
almost everything in the docs the first time. I started understanding
the patterns. After 4 more hours, I had a plugin architecture that
allows me to create multiple view plugins for my outline data (ie. a
graphical view alongside the outline view), import/export for different
formats which even add themselves to the File->Import and Export menus.
I don't know what my luck is, but between Learning Cocoa, the docs
available, www.cocoadev.com, and www.cocoadevcentral.com, I've been
picking up Cocoa faster than any other environment I've ever picked up.
- Use loadable bundles to achieve modularity. For instance, when you
finish the first simple editor, move the domain (model) classes to a
framework, and wrap the controller and the viewer in bundle.
Sounds like a good idea, although I haven't seen any docs on loadable
bundles yet. I'll dig around the Apple developer docs.
Try the AppKit, look at NSBundle. I just spent a few hours playing with
bundles this weekend, and they're so amazingly easy to work with (unless
I'm missing something) that I turned 3/4 of the application I'm working
into clean plugins in an hour, creating an expandable API in the process.
Having come from other environments, it might sound gratuitous to have
so much broken out into plugins, but it's so easy and it leaves your
project so clean if you do it right. There's not much you need to do to
handle bundles, either. Create a bundle target, create a principle
class, load the bundle in your main app, instantiate that principle
class.. and it's all there. Use NSNotifications and a well defined API
to allow plugins to hook themselves into the app environment, and it's
easy.
But as I told, you, it is a matter of taste and team style. BTW, where
do
you see "side effects" in using IB during later phases of a project? I
never seen one...
This may be a case of necessitating "unlearning" the crap that MFC and
AppWizard on Win32 kind of teach people.
The big difference is, all that code that VC++ would generate is gone.
Well, rather, it's there but it's all abstracted away in the system to
create GUIs from NIBs. No templated boilerplate generated code to
allocate, initialize, and place all your controls and things. The only
thing that IB generates are the bits which give the rest of your program
access to the NIB-generated resources.
--
Leslie Michael Orchard <email@hidden>
ICQ: 492905 (home) 11082089 (work)
"...see you space cowboy..."