Module types

Previous  Top  Next

The module types section provides meta-information about the set of item types that may occur as module elements.

Here's what the module-types section looks like for the example flavor com.headway.examples.html:

<module-types sep="/">
   <module-type name="htmlfile" icon="htmlfile.gif"/>
</module-types>

Key points:

·	There is just one item type at this level, namely "htmlfile".

·	Item names in the data file are fully-qualified and use '/' as the token separator (this allows Structure101g to infer the existence of virtual folder items).

·	The icon entry tells Structure101g to use the icon "htmlfile.gif" when rendering items of this type. In fact, this entry is redundant - in the absence of an explict icon declaration as above, Structure101g will always assume an icon "<typename>.gif" by default.

The following snippet from flavor com.headway.examples.osgi is broadly similar:

<module-types sep=".">
   <module-type name="bundle"/>
</module-types>

Key points:

·	Again, there is just a single type declaration at this level, called "bundle".

·	The token separator here is a dot.

·	The icon is not specified so Structure101g will assume "bundle.gif".

There is nothing to stop you having more than one module-type, as long as all the module types correspond to some common broad conceptual category. For example, if we wished to model the domain of C/C++, we might choose to define the following:

<module-types sep="/">
   <module-type name="hfile" icon="file_h.gif"/>
   <module-type name="cfile icon="file_c.gif"/>
</module-types>

In cases such as this, we should also provide an icon that maps to the general category of all declared module types in the virtual types section.