On Sep 17, 2010, at 7:09 AM, Richard Somers wrote:
The reason for the programmatic view is there are lots of similar
views with minor variations between them. Having a programmatic view
allows the objects in the view and the layout and configuration of
those objects to be controlled from a central location.
I am not getting any responses so let me try another approach.
If you inspect the Inspector in Interface Builder you will see that
the one of the views in the Parameters Bindings pane has a view
hierarchy something like this.
IBInspectorSliceTitleView
IBInspectorSliceView
IBStackView
NSClipView
NSScrollView
NSView
If you look for nib files in the Resources folder you may come to the
conclusion that a lot of view composition is most likely done
programmatically for this application. My guess as to why this may be
is because many user interface elements have lot of repetitive dynamic
content all with a consistent look and placement of the elements. I
can't imagine doing some of the IB Inspector panes (View Effects, View
Bindings, View Connections, and View Identity) any way but
programmatically.
Eric Buck recently posted a list of resources for nib-less design.
http://lists.apple.com/archives/cocoa-dev/2010/Sep/msg00417.html
Most of the entries on this list talk about getting a pure nib-less
application to launch with a menu bar. Very little if any discuss how
to programmatically create a view composition with all the objects
setup with connections and possibly bindings in place. Maybe with more
experience it would be more apparent how this is done.
For my specific application I have a collection of programmatically
created root views. The root views are swapped in and out of a
particular location in a window. Each root view is a composition and
creates its own subview objects that go into it. Then I needed to add
logic to dynamically control each root view and its subviews based on
user input and connect it to the rest of the application. For lack of
a better word I will refer to this logic as "control logic". I was
about ready to put the "control logic" into each root view but that
seemed to violate MVC.
So then I thought why not put the "control logic" into a controller
and why not use NSViewController. So now each root view does its own
initial composition during initialization and each root view also has
an associated controller that contains the "control logic". However,
properly initializing and connecting the root view and the controller
has been a challenge and seems like it is going to be messy.
My current inclination now is to change this and do all view
composition, connecting, and binding in the controller. The root view
would still be there but the controller would be doing most all of the
work.
Does anyone else have any experience or anything to say about doing
view composition programmatically?
--Richard
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
