We have finished the current design for composite features.
Find the schemas and sample xml files on the UPDF site.
I suppose everybody has a feeling now what you can accomplish with composite features (c.f. called below). You can basically combine any two or more basic features to a higher level feature. Thinking this over you may better understand why we make some feature pretty basic. I consider it a significant advantage having the chance to save the settings of all basic features, but show something more user friendly in the UI.
The sample implementation on the web site shows a 'Media' c.f. with media size, type and source involved. Might be a common sample. We will develop another more elaborate sample in the area of booklets the next days. If you follow that and understand each detail, you should have the essence of c.f. very well. Do you remember that I referred to c.f. as one of the four pillars more than a year ago? Now you may see why I like it so much. Not to mention that I consider it unique to UPDF.
Some things you may want to check in detail:
1. See the DominantFeature attribute to the CompositeFeatureList. We don't force a driver to work a certain way, but recommendations may help with a better support. That attribute is single, optional. Means it can refer to one feature. In the sample it's media size.
If there is a dominant feature I would recommend to show the defined c.f. in the UI, but automatically remove the composing features from the normal dialogs and make them available in a subdialog collectively. This is an assumption we make in the UPDF standard.
If there is not, you may leave them at their usual locations in the standard dialogs. You can always define additional interdependencies to hide the one or the other control.
With a dominant feature the special c.f. kind of overwrites the dominant feature. That's why we have an optional Name_ID to the CompositeFeature element. In the sample we want media size to be overwritten by Media and the new Name_ID shall be reported to the OS and then show up in the page setup of the applications. Makes sense?
If you want to practice, here's the proposed task: Combine all media types and sources into one merged list of sources like used in a number of today's drivers. And now judge how much code you may need to accomplish that in a monolithic driver - just for this single implementation.
2. If you have a dominant feature, it makes all the other features of a c.f. non-dominant automatically. In our sample that's especially the case with media source. We don't want all the media sources to show up in applications' page setup any more. It would open the door to misselections. We only want the AutoSelect to show up or we could even create a dummy media source with a string "Source is selected by size".
That leads us to the Non_Dominant_Representative attribute, assigned to all feature lists. It's mostly mandatory (only optional for media size and c.f.) and defines one record of the corresponding feature as the fall back to be used within c.f., e.g. given above mentioned dummy or the AutoSelect record. Another nice side effect is that you made the entry unchangeable (as it is just one).
This attribute handles some useful stuff when it comes to communicating setting to the OS.
3. The UserExtensible attribute to the CompositeFeatureList is a boolean and indicates that the driver shall allow the user to create and manage his/her own records additionally to the predefined ones, if set to true. It's up to the driver how to implement that properly.
I hope the other stuff is more or less self-explaining. We have learnt some of our lessons by practicing. During practice there certainly will be the point when you'll say "Wow! Not bad. Now I know."
We are working on a sample driver to allow you trying your sample out.
As I always say: Now that I have that stuff in my mind at a leading position, you'd get quite some solid answers to any questions.
Norbert Schade
69 Prescott Drive
North Chelmsford, MA 01863
978-251-1017
norbertschade@mediaone.net
This archive was generated by hypermail 2b29 : Fri Feb 15 2002 - 12:20:45 EST