I have been working quite a bit with implementing dependencies and have
some comments for the group.
Introduction To Dependencies:
UPDF defines three types of dependencies - filter, message, select. All
dependencies consist of one or more conditions. The conditions are AND'd
together. Each condition can be either and EQUAL or a NOT EQUAL. Conditions
are defined using unique IDs. Therefore, a condition appears as -
MediaDuplex_Record.ID NOT EQUAL Simplex AND MediaType_Record.ID EQUAL
Type_Transparency.
Filter - A filter dependency defines a group of settings (it may be a group
of one) that should never be displayed. If N conditions are defined for the
filter and N-1 of the conditions are true then all settings that would make
the remaining condition true are to be hidden. Using the conditions above,
if media type is set to transparency then all settings with duplex not
equal to simplex are hidden. Also, if duplex is not set to simplex then all
settings with media type equal to transparency are hidden. Filters are not
a very user friendly dependency but they do have their uses.
Message - A message dependency defines a message that should be displayed
when a group of settings (it may be a group of one) is selected. The
message must have an OK and/or a Cancel button. If the user clicks the
Cancel button then the last action performed by the user is undone. If the
user clicks the OK button then a group of settings selections (it may be a
group of zero) is automatically made. In addition, any of the features in
selections may be grayed out and an information icon may be added to the
feature to explain why it is grayed out. Using the conditions above, when
duplex is not simplex and media type is transparency the message "You
cannot duplex transparencies. Click OK to turn off duplexing. Click Cancel
to undo your last change." is displayed. If OK is clicked then duplex is
set to simplex, grayed out, and an information icon is added to the duplex
feature. When the information icon is clicked, the message "You cannot
duplex transparencies." is displayed. All this is defined within the
message dependency.
Select - The select dependency is really a degenerate form of the message
dependency. The select dependency has no message and assumes the OK button
is clicked. So, what you have is a group of settings selection (it may be a
group of one, zero doesn't make sense) that is automatically made when a
group of settings (it may be a group of one) is selected. In addition, any
of the features in automatic selections may be grayed out and an
information icon may be added to the feature to explain why it is grayed
out. Using the conditions above, when duplex is not simplex and media type
is transparency then duplex is set to simplex, grayed out, and an
information icon is added to the duplex feature. When the information icon
is clicked, the message "You cannot duplex transparencies." is displayed.
All this is defined within the select dependency.
Implementation:
This is how I implemented dependencies to provide the results that one
would expect from the UPDF definition.
When the user interface is brought up, dependencies are run against the
saved settings. This should not produce any messages or cause any
selections to be made since the saved settings should be valid. Filters may
cause settings to be hidden from some features.
Each time the user changes a setting by either changing a standard feature
(ie destination changed from top bin to left bin) or changing a composite
feature setting (ie media changed from "plain letter in tray 1" to "plain
legal in tray 2") dependencies are checked. The following steps are then
taken -
1) Save the settings before applying the current change. If the current
change is a composite feature then set all the component features to their
appropriate settings.
2) Make all settings visible (undo any filters), ungray all features, and
clear all information icons.
3) Start dependency checking with those dependencies defined in the user
policy file. The user policy dependencies may duplicate some of the device
description dependencies but are assumed to be more appropriate. For
example, the device description may define a select dependency whereas the
user policy defines the same condition as a message.
4) Check the conditions of each dependency and act on each as appropriate
(filter, message, or select).
5) If a select dependency is true or the user clicks OK on a message
dependency then set the automatic selections and restart dependency
checking (goto step 2) with the new settings.
6) If the user clicks Cancel on a message dependency then stop checking
dependencies and restore the saved settings (from step 1).
I made this mistake in another email so I want to note that if a dependency
grays out and/or adds an information icon to a feature then you do not have
to write another dependency to ungray the feature and/or remove the
information icon. I do this in step 2 above. I think we should make this
part of the definition of UPDF dependencies - When a dependency is no
longer true, features will be displayed normally and information icons will
be removed.
Dependencies and Composite Features:
Dependencies can be defined using standard features or composite features.
A condition can be MediaDuplex_Record.ID != Simplex AND MediaType_Record.ID
= Type_Transparency or it can be MediaDuplex_Record.ID != Simplex AND
Media.CompositeFeature_Record.ID = CF_Media_Transparency. Using the
standard feature, all settings which cause media type to be transparency
will cause the condition to be true whereas using the composite feature
will only cause condition to be true for a specific composite feature setting.
One other use of dependencies is for user extensible composite features. A
composite feature record should not be defined that causes any dependency
based on the components of the composite to be true. For example, if a
media composite feature has the components media size, type, and source and
there is a dependency that says #10 envelopes can only come from the
envelope feeder then the user should not be able to create a composite
feature record with a media size of #10 envelope and source not equal to
the envelope feeder.
I have not implemented this portion of dependencies yet but my plan is that
during the definition of a composite feature record I will apply only those
dependencies that have all condition features as components of the composite.
If you've read this far, I hope I've helped you understand dependencies a
little better. Please feel free to respond with questions and comments.
Jim
mailto:sommer@granitesystems.com
978-486-3068
This archive was generated by hypermail 2b29 : Thu Sep 26 2002 - 08:55:48 EDT