Re: Conditionally modifying NIBs?
Re: Conditionally modifying NIBs?
- Subject: Re: Conditionally modifying NIBs?
- From: Jonathan Hess <email@hidden>
- Date: Thu, 15 May 2008 13:36:33 -0700
On May 15, 2008, at 4:25 AM, Mike Fischer wrote:
Am 15.05.2008 um 02:20 schrieb Jonathan Hess:
As for the original question, you can modify an IB file, to some
extent, using ibtool --import and ibtool --export. For example, you
might consider placing all of your views and objects in the XIB/
NIB, and then using these options to control the isHidden property
of various views.
That's certainly the most interesting idea I've heard so far. So
with this method I could in theory assemble different nibs into a
single one at build time?
That won't be easy though, as it isn't an intended usage of ibtool.
I think the best option here is to make the changes in code, and to
only use on IB file.
I gather that IB is apparently not meant to allow for scripted build
processes. It seems to be a purely graphical tool operated manually.
For many purposes this is fine. But once you have a complex nib and
want to make incremental changes or changes dependent on some build
setting it becomes very complicated.
Yes and No. ibtool isn't meant for arbitrarily modifying NIB's, but it
is meant to be worked into the build process to do things like
automatically validate NIB's, or automatically preform incremental
localizations.
Even worse IMHO a nib can hide many rather important settings making
it very hard to understand for someone who is not the original
author for example. This makes nibs very fragile because small
mistakes in say connecting things can lead to program errors that
are hard to debug later on.
Good Luck -
Jon Hess
Yes thanks! I keep wondering though how companies that make large
complicated apps in teams are coping with these limitations. I can't
imagine building something like Photoshop using nibs for everything
and working on a nib with more than one person. I'd guess one would
use nibs for simple things and possibly building blocks and do
everything else at run-time where what happens is clear and self
documenting.
Just like small source files that only aggregate related functionality
help keep source code readable, the best way to keep your NIB files
maintainable is to keep them small. Take a look at the contents of
Interface Builder.app in Xcode 3.0, it's filled with hundreds of small
NIB files. Most controller's go with exactly one view or window, and
if you can, it's best to keep the NIB files to one top level view or
window + one main controller (not counting controllers used for
bindings). If you have a large window with many different sub-
components, consider breaking the subcomponents out into separate NIB
files with just top-level views. A good rule of thumb is probably that
if a piece of UI requires its own custom controller (in the classical
sense, not the bindings sense), it should probably have it's own NIB.
If you do this, it usually makes your NIB files relatively easy to
understand, and greatly reduces the chances of conflict in your SCM
system.
Good Luck -
Jon Hess
Mike
--
Mike Fischer Softwareentwicklung, EDV-Beratung
Schulung, Vertrieb
Note: I read this list in digest mode!
Send me a private copy for faster responses.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden