mm interesting reading!... I'm trying to see how I could implement
this in my case...I used the "Tool" example as it seemed easier to
explain but basically, what the abstract class represents is an
"Operation" (just a simple operation performed on some text...)..
example of subclass could be "Insert text Operation", "Replace Text
Operation" etc... basically an operation has some parameters
(textToInsert, textToSearchFor etc..) and it takes some text, performs
a transformation on it and returns a string... the custom views are
just used to set those operation's parameters (text to insert
etc..)... I thought of several way of doing it but since an operation
could have boolean, int or string parameters, I figured having a
custom view for each operation would be the way to go...
So to sum it up, each operation has a set of parameters, controlled by
a custom view ... but the user can add as many operations as he wants
(so it's not really like there will be only 1 instance of each
operation... which makes things a little more complex than if it were
just a tool...)
Basically this is the idea... anyway it's almost 4am I'll have to re-
read your post tomorrow morning and see how I can make this work for
my situation! :) in any case, thanks for the ideas!
On 24-Nov-08, at 3:32 AM, Graham Cox wrote:
On 24 Nov 2008, at 6:17 pm, Jean-Nicolas Jolivet wrote:
What I'm trying to do is a bit weird but, it seems to be the only
way I can think of implementing such a concept, anyway I'll do my
best to explain... so I have an abstract class (let's call it
Tools)... basically it just defines some methods/properties that
the subclass should implement (as I said... an abstract class)...
Each subclass of Tools must have a different custom view assigned
to it (i.e. the "Pencil" class, which is a Tool subclass, has a
custom view, the "Paintbrush" class has a custom view etc...), so I
added a "NSView *view" properties to my base "Tool" class.
The problem is, I'm not sure how I can store those custom views and
associate them with their respective subclasses once they are
instantiated. I'm able to do it if each views are in separate nib
files, that way I just add a "nibName" property to my Tool class,
so that every subclass of it has a distinct nib name, I load that
nib and load the only view in it...
however, this doesn't really seems like the ideal way of doing
this... wouldn't it be more practical to save all those views in
only one nib file? But the problem is, if I do it that way I don't
know how to access a specific view from that nib file... I thought
about trying to access it via the "Interface Builder Identity" name
property but apparently this isn't accessible programatically...
Obviously, if I store all my custom views in the same nib file, and
each subclass of Tool has to be associated with one of those custom
views, I can't really set a File Owner to that nib file and define
an outlet to be associated with any of the view since the "File
Owner" could basically be any of Tool's subclasses....
Should I just store each custom view in their respective nib
files??? Or perhaps I'm just looking at this the wrong way?
Any help would be appreciated...
Is the idea that as one selects a tool, a pane is switched to show
the tool's options?
If so, and all the views are in the same window, then I'd put all
the views in the same nib (one window = one nib). Then you can
simply have outlets to each view and install the one you want given
the selected tool. Easier still is to use a tabless tab view and
switch the current tab.
I'd also resist somewhat the idea of each tool having a "view"
outlet. While that seems an obvious way to link a tool with its
options, it's breaking MVC a little bit, though it depends on your
app's concept of a tool of course. I'd have a tool controller that
receives the tool selection and installs the relevant options view.
One way I've done this in the app I'm currently working on is to use
a simple naming convention for the outlets to the views which is
related to the name of the tool. Then I can simply look up the
relevant view by taking the tool's name, building the outlet name
from it, then using valueForKey: on the controller to return the
outlet which gets processed further (by installing the view into the
window in my case). It's very extensible and means that the tool
controller doesn't need to know about all the different tool
classes, only that the generic tool has a name, and that the outlets
follow a simple naming scheme.
I can't see any benefit to having each view in separate nibs if this
indeed what you're trying to do - it's an extra level of complexity
that isn't worth the trouble.
hth,
Graham
Jean-Nicolas Jolivet
[EMAIL PROTECTED]
http://www.silverscripting.com
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
