Multiple instances of a nib without multiple loads?
Multiple instances of a nib without multiple loads?
- Subject: Multiple instances of a nib without multiple loads?
- From: "James Farwell" <email@hidden>
- Date: Tue, 22 Jul 2003 12:51:47 -0700
Greetings all,
I am writing my own custom "Rule List View" which attempts to mimic the rule
lists like those in iTunes' smart playlists, Finder's advanced find, and
Mail's filters. The catch is, I am writing my list for an application which
adds new rules from 3rd party plugins, so I need to account for the contents
of the rules being completely dynamic. My current implementation makes
pretty liberal use of loading nibs on the fly, and while it does not seem to
impact performance for the short lists (< 15) of rules I have been testing
with it, I am aware it does not scale very well.
In my implementation, each "row" of the list is defined by 2 nibs. The
first nib is simply an NSView which contains the elements which are constant
in each row: the drop down list of all possible rules, and the buttons to
insert and remove rows. It also has a custom view for the controls that
define the rule.
(bad ASCII art)
_________________________________
| _________ ############# _ _ |
||v|__list_| #Custom View# |+||-| |
|____________#############________|
When a rule is chosen from the list by the user, the program creates a new
instance of the rule class (this is necessary due to the fact that each
instance of a rule in the list has its own nib, so the IBOutlets have to
connect to a unique instance somewhere in order for me to use them), which
in turn loads its respective nib (another simple NSView containing whatever
controls the rule needs) and sets it as the custom view. The rules
themselves are pretty simple. They get passed in data from the app, perform
their action on the data (using the contents of their controls, hence why
the IBOutlets are necessary) and then return the result.
So, now that I've explained the basic mechanics, it is pretty plain to see
that there is not only quite a bit of nib loading here, but also a lot of
nib duplication. If a user made a list with 5 different instances of the
same rule, then there would be 5 different instances of that rule class and
5 separate loads for the 5 separate instances of the nib for that rule.
Can anybody think of a way to simplify this setup without impacting its
flexibility? The rule classes themselves could almost be made entirely of
class methods except for the fact that they need to access the IBOutlets of
their nibs. It almost make more sense to have them be class methods and
just pass in a dictionary of the contents of the rule, except then there
would still need to be a new instance of some class to hold the IBOutlets,
so what's the point in complicating it by splitting it into 2 classes. Is
there any way to have instances of the same rule to somehow share a nib, yet
have separate IBOutlet connections?
Thanks!
- James
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.