Re: Use different window than File Owner's in NIB
Re: Use different window than File Owner's in NIB
- Subject: Re: Use different window than File Owner's in NIB
- From: James DiPalma <email@hidden>
- Date: Tue, 6 Jul 2004 14:04:37 -0700
On Jul 5, 2004, at 7:42 PM, David Bainbridge wrote:
but I was hoping for a less obtrusive way that didn't require the
headache of maintaining multiple files on disk and in the project..
looks silly having "...controller2.nib", "...controller3.nib", then
decide #2 is the one you want and have to go back and rename that nib
to the "correct" name..
I don't understand, but you are clearly unhappy with this solution. If
you have 3 ui designs for a complicated window, a single nib file with
all of these objects will be difficult to maintain. I am uncomfortable
having many objects in any given nib file, so 3 designs for a
complicated window all in a single nib file is not something I would
do. If you are comfortable with it though, that is what you should do.
the windows do not require to be loaded at the same time...
If your two windows are both in a single nib file, they will both get
loaded (as defined by loadNibNamed:) but they won't get loaded (as in
loaded/shown/orderedFront to screen). I have heard a few requests for
loading nib files in parts; do you want only part of your nib file to
get loaded?
just so someone can view one then the other.. I would have thought
this was a somewhat common need since the "test interface" in IB only
goes so far with complicated windows...
InterfaceBuilder is a great tool and was designed to take advantage of
a dynamic language and a framework of objects that can
archive/unarchive. Since IB can only test interface behavior of code it
is linked with, it can test resizing and simple action messages, but is
unable to test project code that is not linked into a loaded palette.
I have seen a few palettes over 14+ years of working with
InterfaceBuilder that push far far further than simply testing resize
springs. If you want better test interface behavior, you can look into
writing a palette and try promoting more palette writing (personally, I
don't usually like palettes, but that is a long story that is likely to
change).
I do have some more suggestions:
- Localization. Pretend your design iterations are localizations
- Cvs. Check out multiple copies of source
- setWindow. Use a simple setWindow: style controller
- Controller. Change your design to use a data manager/controller/owner
Localization. If you put your design iterations into a localized lproj
directory, you can switch to say French and load your nib file. This
idea also adds files to your filesystem, but does not require changing
a file name which is probably a code change. So, your headache is a
little different. This solution has an advantage that users can easily
switch between your different designs.
Cvs. If your source is in some kind of source management system like
cvs, you can check out multiple versions and compile two different
applications that have your ui design variations. This solution has
some extra clutter involved, but it is easy to do, does not require any
code or nib changes after you decide, and is easy to check in both
versions after you make a decision (check in bad, check in good, keep
both versions in cvs).
setWindow. If your change is as simple as choosing which window to
show, which won't work if your controller, acting as file's owner,
requires outlet connections to do its controlling. If it is just a
window, a simple controller could choose which window then call
setWindow: on your file's owner object.
Controller. As a design, using a window controller to control views
within a window has both advantages and disadvantages. This design is
well documented in both Apple docs and in various Cocoa books, it puts
all of your code into a single object which can simplify where your
code is and help reduce how many objects are in a "complicated" window.
But, it relies on using a file's owner object to have connections to
view objects in your nib file.
A different design could use a file's owner object that provides data
to a nib instantiated controller that handled interacting with views
within your nib file. This file's owner would be more like a data
manager (if it used a data model instance to relay data), or a data
owner (if it owned this data), or a data controller (like an
NSDocument, but this design would likely require outlets and not be a
real change). Your nib-instantiated controller would have an outlet to
your file's owner, get what data it needed and then interact with your
ui. With this design, it would be easy to instantiate multiple
controllers to control multiple windows.
-jim
BTW, If there is a better solution available from a Java or C# tool,
I'd am curious to hear it; these tools, in my experience, focus more on
code generation and rely on their ide to do anything like test
interface.
_______________________________________________
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.