I have a set of, let's say three, devices that have a range features among
them: a common, base feature set and then some combination of A, B or A + B
on top of that common base.
When the user is managing and configuring these devices from a list (a table
view for example), I bring up a dialog box that allows the user to configure
the device and the features:
.-----------------------------------------------------------------.
| O O O Window/Sheet/Panel |
|-----------------------------------------------------------------|
| |
| Common |
| Features |
| & |
| Configuration |
| |
|- -- -- - -- -- - -- -- - -- -- - -- -- - -- -- - -- -- - -- -- -|
| | |
| Feature Set A . Feature Set B |
| Configuration . Configuration |
| | |
|- -- -- - -- -- - -- -- - -- -- - -- -- - -- -- - -- -- - -- -- -|
| |
| .----------. .------. .--------. .-------. .------. |
| | Previous | | Next | | Cancel | | Apply | | OK | |
| '----------' '------' '--------' '-------' '------' |
!_________________________________________________________________!
Right now, I realize the view with a controller for a single device with:
typedef boost::shared_ptr<FooDeviceBase> FooBaseDevicePointer;
typedef std::vector<FooDeviceBasePointer> FooBaseDeviceCollection;
+ (FooDeviceSettingsController *) withDevice: (FooBaseDevicePointer
&)inDevice;
- (id) initWithDevice: (FooBaseDevicePointer &)inDevice;
or for multiple devices with:
+ (FooDeviceSettingsController *) withDevices: (FooBaseDeviceCollection
&)inDevices;
- (id) initWithDevices: (FooBaseDeviceCollection &)inDevices;
and then just disable features and options not available for a given device
when the view is instantiated and as the user cycles through "previous" or
"next".
However to avoid user confusion and frustration over greyed-out (i.e.
disabled) features they can't seem to access or enable, what I'd rather do
is have a series of (sub)views for each feature subset. In effect, there'd
be a device-specific view (say DeviceXSettingsView, DeviceYSettingsView and
DeviceZSettings) for each device and that view is a has-a-view composition
among the common, A and B (sub)views:
DeviceXSettingsView
has-a CommonFeatureView
DeviceYSettingsView
has-a CommonFeatureView
has-a FeatureAView
DeviceZSettingsView
has-a CommonFeatureView
has-a FeatureAView
has-a FeatureBView
In the absence of one subview or another, the super view and sub views would
adjust accordingly (common snaps down to the buttons in the absence of A and
B, A fills right in the absence of B, B snaps right in the absence of A,
etc.).
I think it's pretty straightforward how to do this programmatically;
however, it seems like I should be able to avoid that and do 90% of the work
in Interface Builder. Basically, establish a custom view class for each of
the above described subviews (CommonFeatureView, FeatureAView,
FeatureBView), a NIB in IB for each using those custom view classes. If I
can do this, is it best to have a NIB for each subview or pack them all into
a single NIB? Six of one; half dozen of the other?
I suspect I could also do this by adding/removing tabs and having a view for
each. Unfortunately, the base case of one tab (which ostensibly should just
be a box) seems like bad user interface form.
Are there any good URLs, books or code samples (Apple or otherwise) that
anyone can recommend that demonstrate this sort of thing? I've not yet come
across one in /Developer/Examples/... that seems similar enough in scope.
Thanks,
Grant
_______________________________________________
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
