Re: IBPlugin embedding question
Re: IBPlugin embedding question
- Subject: Re: IBPlugin embedding question
- From: WT <email@hidden>
- Date: Thu, 25 Jun 2009 01:10:48 +0200
Hi Doug,
I don't have any experience in designing and implementing IB plugins,
but I thought I'd pass along an observation that has served me well on
occasions when I needed to make error-prone changes to many similar
nib files (well, xib files, actually): xib files are xml files, so
they're amenable to text-editing.
If the changes you find yourself making are reasonably structured, you
could write a script that processes your plugin xib files and add a
run-script phase to your build system.
Wagner
On Jun 25, 2009, at 12:46 AM, Doug Scott wrote:
Question: How can I automate the maintenance of embedded IBPlugins.
Xcode Version 3.1.3
Interface Builder Version 3.1.2 (677)
I have developed a small series of custom IBPlugin framework
projects, two of which include other custom IBPlugin objects. Here
is a quick overview of the hierarchy.
- IBPlugin-A: A view with a custom API.
- IBPlugin-B: A view which adds a set of controls to manipulate the
embedded IBPlugin-A view via its API.
- IBPlugin-C: A view which embeds two IBPlugin-B views side by side.
- Application-D: Contains a nib with a view which contains an
IBPlugin-C view.
- Problem: Change is pure drudgery. When I make even the most
trivial change to IBPlugin-B I have a long string of manual 'fix-
ups' I must do to make everything once again function correctly in
Application-D.
- Solution of the moment: Think thrice before I make a change and if
it is 'worth it' go ahead and change it - then pay the price.
- The price: Details withheld for brevity. Suffice it to say there
is a lot of manual dragging and dropping and outlet connection
repairs and terminal install builds at each level up the chain of
IBPlugin frameworks and IBPlugin Librarys and nib views as old
custom view objects are deleted and new ones dropped into their
place and reconnected to their outlets. Miss one step somewhere and
nothing works - start over dude!
Although I'm quite happy with the end results of being able to
utilize nested IBPlugins of ever encreasing complexity I'm not at
all happy with the ever increasing complexity needed to manually
repair everything up the chain when I make a simple tweak to a lower
level custom IBPlugin. This problem appears to make future expansion
of embedded IBPlugins almost impossible to maintain as I'd have to
do the manual fix-ups to every future IBPlugin and every application
and every nib that used an IBPlugin that is modified. This way lies
madness.
In the realm of compiled code I simply 'include' a framework or
'import' external sources and it all gets picked up 'automagically'
by all code that uses external code. But in the 'visual' world of
Interface Builder it seems to require human intervention at every
step of the way. I do not see any way for the different views to
'include' other views indirectly, only by manually adding the
objects via drag and drop can an IBPlugin be upgraded to utilize
another custom IBPlugin's visual elements. Nib files seem to be only
a static 'snapshot' of a point in time during the development
processes, and not really part of a modern dynamic build system.
I'm hoping that I missed the point somewhere along the long and
painful journey I've travelled in my quest to pound IBPlugins into
submission and that wiser heads will be able to lead me to wisdom.
-Doug Scott
_______________________________________________
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