Re: IBPlugin embedding question
Re: IBPlugin embedding question
- Subject: Re: IBPlugin embedding question
- From: Doug Scott <email@hidden>
- Date: Thu, 25 Jun 2009 10:20:23 -0700
On Jun 25, 2009, at 9:38 AM, Shawn Erickson wrote:
On Wed, Jun 24, 2009 at 3:46 PM, Doug Scott<email@hidden>
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.
I really don't understand why you are hitting an issue. I have
developed several IB plugins (both pre 3.0 and 3.0 based) and never
have go myself into the issue(s) you seem to be hitting.
Also I don't understand why you have so many IB plugins well... what
do you mean by "IBPlugins" in the above?
-Shawn
I mean exactly that; IBPlugins - plural.
The bottom of the embedded chain is IBPlugin-A. It is built and
installed and becomes an object in the IB Library panel.
I drag an IBPlugin-A object out of the IB Library panel into the
IBPlugin-B projects view and surround it with controls and wire it all
up to IBPlugin-A. IBPlugin-B is then built and installed and becomes
an object in the IB Library panel.
I then drag two copies of IBPlugin-B objects out and drop them into
the view in the IBPlugin-C project and wire it all up, but only to
IBPlugin-B (usually). The resulting IBPlugin-C is built and installed
and becomes an object in the IB Library panel.
I then drag an IBPlugin-C object out and place it into a view in
Application-D and wire it all up to the two IBPlugin-C objects and
build and install Application-D and then the whole chain of IBPlugins
just 'do their thing' at run-time, all nicely nested within each other
as I intended and it all 'just works' ( thanks Apple! ).
It is just like dragging out a complex Apple provided object which
contains embedded scrollers and such. I don't have to connect the
Apple supplied scrollers to the Apple supplied scrolling view, Apple
did it with embedding ( or could have if they chose to do it that way,
I don't really know how Apple's stuff is built ). At each level of
embedding the embedded object maintains its own internal outlet
connections and I only have to wire up the new outlets required by
each outer container IBPlugin and drag a connection to and from the
embedded IBPlugin or IBPlugins to connect the outlets for
communication from the higher level to the lower level and back. This
way at each level things stay simple with the embedded object
complexity dealt with by the embedded object only and each higher
level object driving the lower level object and listening for any
responses.
I choose to separate things into multiple levels of increasing
complexity because each of them has a very specific role to play and
each of them can stand alone in various view nibs of any Application-X
if their specific level of functionality is all that is needed.
Unfortunately the only way I've found to do all this is a purely
manual process and the complexity issues grow rapidly and the level of
maintenance drudgery becomes unbearable.
-Doug
_______________________________________________
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