Home >> All >> org >> greenstone >> gatherer >> [ cdm Javadoc ]

•	org.greenstone.gatherer.cdm.custom.* (1)

• org.greenstone.gatherer.cdm: Javadoc index of package org.greenstone.gatherer.cdm.


Package Samples:

• org.greenstone.gatherer.cdm.custom

Classes:

• Format: This class encapsulates all the information about a format command from the collection configuration. This includes both the 'general' formatting commands, and the commands targetted at specific classifiers or classification component types. This class is, unfortunately, the most complex in terms of DOM model support, since we have to maintain a live reference to any classifier this format applies to. We temporarily use the feature name as the format name attribute but since the order of classifiers can change, this of course gets horribly out of date. Before the CollectionDesignManager saves the ...
• CommandTokenizer: This class provides an extension to the standard StringTokenizer in that it recognizes quotes (or some form of bracketting) enclose a single token so in something like: format Search '<table><img src=... </table>' the formatting string is parsed as a single token. Unfortunately this makes countTokens() unreliable for exact measurement of tokens remaining, and only useful for determining if there are tokens left to be processed (includes any that have already been read into command buffer).
• GUI: This class is responsible for generating the necessary GUI components. It does this by calling the getEditControls() method of the appropriate class (i.e. IndexManager for index related edits). It also is in charge of correctly adding (and removing) listeners, using phrases from the Dictionary rather than the text keys inserted in the component classes, and several other aspects of the design page, including the config file section tree.
• GeneralManager: This class is responsible for generating the necessary GUI components. It does this by calling the getEditControls() method of the appropriate class (i.e. IndexManager for index related edits). It also is in charge of correctly adding (and removing) listeners, using phrases from the Dictionary rather than the text keys inserted in the component classes, and several other aspects of the design page, including the config file section tree.
• TranslationManager: This class provides a graphical interface to allow a user to quickly and conviently (ie all in one place) translate the text fragments associated with general metadata and indexes into each of the assigned languages in the collection. It should provide clear controls for the editing of these text fragments, plus clear indicate what languages still need further translation, which it will do through a combination of coloring and other visual indicators.
• TranslationView: This class provides a graphical interface to allow a user to quickly and conviently (ie all in one place) translate the text fragments associated with general metadata and indexes into each of the assigned languages in the collection. It should provide clear controls for the editing of these text fragments, plus clear indicate what languages still need further translation, which it will do through a combination of coloring and other visual indicators.
• CollectionConfiguration: This class provides either access to a pseudo-G3 document, or parses a collect.cfg file in such a way as to provide an xml-type view of its content. This later version is useful as it allows the manipulation and free form editing of a legacy collect.cfg file while still allowing the various CDM data managers to base themselves directly on this model (whereas they used to be independant ListModels which clobbered the ordering of unparsed commands).
• MetadataSetView: Unlike its namesake in the msm package, this class really only knows how to produce a simple visual representation of the currently imported metadata sets. It is also read-only, so should be fairly straight forward. (It has no namesake any longer as my co-programmers found this far too confusing - however I have now added a CollectionConfiguration to the cdm package just to keep them on their toes!)
• SuperCollectionManager: This class contains the information about what supercollection has been specified (if any) and methods for changing this information. Note that there is a major difference between this manager and the others in that its DOM model is never used directly in any list component. It is only used to decide whether a certain entry in the actual checklist is checked.
• CollectionDesignManager: This manager provides access to submanagers, which in turn provide tools for the designing of Greenstone collections via the information stored in etc/collect.cfg. This class acts as a hub for the managers that handle specific parts of the configuration such as classifiers, format strings and language settings.
• IndexManager: This class is resposible for storing the indexes which have been assigned to this collection and the default index, and providing methods for interacting with both these data pools. It also knows how to turn itself into a String as it would be displayed in the collection configuration file.
• SearchType: This class represents a single search type setting which means that, at the moment, it is either based on an Content element containing the string 'plain' or one on the string 'form'. The ordering of these elements within the SearchType element is important.
• Level: This class represents a single search type setting which means that, at the moment, it is either based on an Content element containing the string 'plain' or one on the string 'form'. The ordering of these elements within the Level element is important.
• ElementWrapper: For even more confusion this class provides a convience wrapper around an element, to allow it to appear in the JList with both name and description. However this class has nothing to do with its namesake.
• MetadataSetManager: Unlike its namesake in the msm package, this class really only knows how to produce a simple visual representation of the currently imported metadata sets. It is also read-only, so should be fairly straight forward.
• Classifier: This class is responsible for storing information from a parsed classinfo.pl call in such a way that it allows easy access to parsed details for the purposes of user design and specification of classifiers.
• PlugIn: This class is responsible for storing information from a parsed pluginfo call in such a way that it allows easy access to parsed details for the purposes of user design and specification of plugins.
• ParsingProgress: This class provides a progress bar to be displayed whenever the module must reload the plugin and classifier information, either automatically or if the user indicates a reload is needed.

Home | Contact Us | Privacy Policy | Terms of Service