| Home >> All >> org >> greenstone >> [ gatherer Javadoc ] |
Page 1 2
• org.greenstone.gatherer: Javadoc index of package org.greenstone.gatherer.
Package Samples:
• org.greenstone.gatherer.cdm
• org.greenstone.gatherer.cdm.custom
• org.greenstone.gatherer.gui
• org.greenstone.gatherer.gui.tree
• org.greenstone.gatherer.gui.messages
• org.greenstone.gatherer.gui.table
• org.greenstone.gatherer.gui.border
• org.greenstone.gatherer.gui.combobox
• org.greenstone.gatherer.gui.metaaudit
• org.greenstone.gatherer.gui.browser
• org.greenstone.gatherer.mem
• org.greenstone.gatherer.msm
• org.greenstone.gatherer.msm.parsers
• org.greenstone.gatherer.file
• org.greenstone.gatherer.help
• org.greenstone.gatherer.sarm
• org.greenstone.gatherer.collection
• org.greenstone.gatherer.shell
• org.greenstone.gatherer.checklist
Classes:
• MetaAuditFrame: The MetaAuditFrame provides a table view of all of the metadata assigned to a selection of FileNodes. All values for a certain file and a certain metadata element appear in the same cell. This table can be sorted by any column, and also has a MS Excel-like AutoFilter allowing you to restrict the rows visible to only those that match a certain set of criteria (applied to each column, and then 'ANDED', or cojoined, to determine the filter). Finally this dialog does not block the Gatherer tool, so the file selection can be changed and the dialog will just generate a new table dynamically. Much effort ...
• CreatePane: This class provides a GUI view showing some statistics on your current collection, and options for building it. As the collection is built this initial view is replaced with one showing progress bars and a message log of the creation process. This log can be later accessed via the options tree located in the center of the initial pane. This class is also responsible for creating the GShellProgressMonitors that are then attatched to external shell processes, and calling the methods in the CollectionManager for actually importing and building the collection. The (i)mport and/or (b)uild options supported: ...
• GDMManager: This object manages the metadata attached to file records. By storing all of the metadata in one place you garner several advantages. Firstly only one copy of each metadata object is retained, all actual entries are converted to references. Next you can immediately determine what metadata is assigned to an entire directory, thus the metadata.xml files can be built more effeciently (whereas the current 'optimal' method uses recursion through the tree contents). Finally, and perhaps most importantly, it allows for dynamic 'on demand' lookup of metadata. This is especially necessary with large collections, ...
• Dictionary: Extends the ResourceBundle class to allow for the automatic insertion of arguments. Note that the key names beginning Farg are reserved for formatting. Property files usable by this class have the Backus-Naur form: FileLine ::= Comment | Mapping Comment ::= '#' SString Mapping ::= NZString ':' SString ( Argument SString )* NZString ::= ( Char | Int ) SString Argument ::= '{' Int '}' SString ::= String . ['"','#',...] -> ['\"','\#',...] In order to add a new dictionary Locale, simply copy the existing dictionary.properties files, replace the values (Strings after the ':') with the new language specific ...
• SynchronizedTreeModel: This synchronized TreeModel is comprised of two seperate models. The extended model is used to paint the screen, and can only be updated on the AWTEvent Thread. The second, private, model contains the current actual state of the model with changes made immediately. If such changes occur then a task is queued in the AWTEvent Thread to update the 'painted' model. This model depends on the TreeNodes used having these properties: TreeNode x_node = new TreeNode("x"); TreeNode y_node = x_node.cloneNode(); for(int i = 0; i < x_node.getChildCount(); i++) { x_node.getChildAt(i) != y_node.getChildAt(i); ...
• LegacyCollectionImporter: Importing metadata from legacy collections requires three distinct steps: 1. Import hfiles and build value tree for the appropriate element. This is quite tricky as the only place to determine the relation between hfiles and the elements is the collect.cfg file. Fortunately we can reuse a lot of code from SearchForMetadata. 2. Recurses through the import folder of a legacy collection, and prompts the user how to transform old skool metadata names into the new and improved namespace standard. Because of the optimization of only opening each metadata.xml file once, this method is so different from ...
• MetadataEditorManager: Provides a GUI and relevant suite of tools for the editing of the metadata set associated with this collection. Again I have tried to capture a file manager type feel, with a tree showing the various set-element relations to the left of the dialog, and the right side showing details on the current tree selection. When a set is selected these details include a list of attributes, while when an element is selected this list is joined by another showing assigned values. In order for the editor to be stable and consistant with the rest of the tool, care must be taken for fire appropriate events whenever ...
• AutofilterDialog: The autofilter concept comes from Microsoft Excel spreadsheets that use autofilters to filter to the sheet. When you click on the heading of a column, a new prompt allows you to specify what filter should be acting apon the selected column. Any new filter is conjoined with any previous filters to provide a sheet containing only rows that match all current filters. Each column must also provide an indicator for determining if a filter is set (in this case a special icon) and and a method for removing a filter (use the clear filter button within the autofilter dialog). Having recently discovered ...
• CollectionPane: The collection pane is analogous with a file manager. It is there that the user chooses which files to include in their collection and what structure the file hierarchy should take. The later aspect is not important for the Greenstone Suite, but is usefull for grouping files for ease of metadata markup. The view essentially consists of two file trees, one denoting the entire source workspace and the other the files within your collection. The trees themselves have a title bar at the top, a filter control at the bottom, and are coloured to indicate activity (grey for disabled). The remainder of ...
• GTableModel: Provides the model for a GTable component, filling it with metadata values for the choosen files or folders. The model also provides several different view of this data; assigned folder metadata, assigned file metadata, all assigned metadata, unassigned metadata, and all metadata. It also differentiates between metadata that is common to all of the files or folders, and that which isn't. The building of the actual model is done on a separate thread so that the gui remains responsive, and the gui is intermitantly updated by this thread. Updating of the model is triggered by events recieved from ...
• 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 ...
• SynchronizedTreeModelTools: Due to the TreeModel objects not having any synchronization, certain assumptions, such as the model state remaining constant during a repaint, don't always hold - especially given that I'm changing the tree model on a different thread. In order to get around this I will use the latest swing paradigm wherein you flag a section of code to be executed by the AWT GUI Event queue, as soon as other gui tasks have finished. This way I shouldn't have tree redraws throwing NPEs because the array size of the children of a certain node has changed -while- the repaint call was made, i.e. repaint() calls getChildCount() ...
• Filter: This object allows the user to set a filter on one of the workspace trees, specifying a preset type, or a regular expression that a files must match to be in the tree. Note that all directories are included. This class includes the controls for editing the filter. The trick is that several instances of the Filter class can share the same internal data (termed a 'run' of filters), so that the filter set on the CollectionPane and the MetaEditPane are virtually the same. The regular expression typed uses '*' as a wildcard character (equivalent to '.*'), and does not use '.' to match any single character ...
• AppendLineOnlyFileDocument: A Document whose underlying data is stored in a RandomAccessFile, and whose Element implementations lack the memory hogging problems associated with anything that extends the AbstractDocument class. This Document, for reasons of time constraints and sanity, only provides an editting ability of appending new lines to the end of the current document, perfect for our logging needs, completely useless for text editing purposes. Furthermore, since the append actions tend to somewhat swamp the IO, I'll temporarily store strings in the structure model, and write them out using a separate thread.
• ModalDialog: An extension of the JDialog that overrides the JVM's typical modal behaviour. This typical behaviour is that when a modal dialog is opened, all other windows cease to respond to user events until the modal dialog is disposed. However this prevents us opening the help documents property whenever a modal dialog is open. Thus we override the modal behaviour so that only the owner frame or dialog is blocked. Note that because we always call the super constructor with modal set to false, this should be made visible with setVisible(true) rather than show() which will return straight away.
• ExistingMetadataLoader: Attempts to locate and import any metadata already attatched to files about to be imported. This entire function is part of a critical file copy and so must be fast and reliable (or at least recover nicely when things go wrong). Futhermore this process must be aware of concerns such as previous greenstone collections having metadata sets that could be immediately imported, or hierarchy files needed to turn indexes into something more meaningful. We also must allow for the extensibility of this class to include custom metadata objects such as MARK records etc.
• StaticStrings: Were you to guess that this is a class object choc-a-block full of static stringy goodness, you'd be right. They come in several flavours: Those ending _STR are strings you might find as values in XML, _ELEMENT are element names, _ATTRIBUTE are attribute names, _CHAR are particular characters while _CHARACTER are also characters but expressed as strings (for regex purposes ie startsWith, endsWith, indexOf and replaceAll); _PATTERN are strings which require extra escaping to put them through regex. Finally anything else is just a static string used within GLI.
• LongProgressBar: A progress bar that doesn't pack a sad when you feed it longs (such as the sizes of files) which get mangled into negative numbers. I know how it feels, as I often have negative progress. Also tries to be efficent when updating the JProgressBar, so only updates when the value actually changes, which become necessary when you move a large number of files with millions of bytes (where upon shifting a file of a thousand bytes would be pretty insignificant, maybe not even a percent, but would fire several progress updates).
• 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).
• GreenstoneMetadataParser: Provides a metadata parser implementation that knows how to locate, prepare for, then import metadata from a previous Greenstone collection. Is aware of such factors as the presence of Metadata Set files and hierarchy files. Updates the profiler where possible to allow for faster subsequent imports from a certain collection. Caches all the information about encountered collections in CollectCFG objects which are softly cached (ie are cached, but are reclaimed before an OutOfMemory exception would be thrown).
• UndoManager: Manages the rather complex task of undoing and redoing actions. It does this by storing two queues, undo and redo, containing undo jobs which encapsulate all the information needed to undo or redo an action. It is also important to note that the manage creates a temporary directory, and then places any deleted files in this directory, and saves their associated metadata with them, for the life of the session. This is to facilitate the restoring of deleted files.
| Home | Contact Us | Privacy Policy | Terms of Service |