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

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


Package Samples:

• org.greenstone.gatherer.util

Classes:

• 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); ...
• 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() ...
• 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.
• 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.
• WinRegistry: This class provides access to the Windows registry via the preferences modules of JDK1.4. But wouldn't you know it, it doesn't always read the windows key files correctly as they appear to have changed how they store keys between win98, win2000 and winNT. To combat this, this class will eventually be swallowed by the LauchProgramManager, and used only to attempt to determine the default launching commands.
• SwingWorker: This is the 3rd version of SwingWorker (also known as SwingWorker 3), an abstract class that you subclass to perform GUI-related work in a dedicated thread. For instructions on using this class, see: http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html Note that the API changed slightly in the 3rd version: You must now invoke start() on the SwingWorker after creating it.
• DragGroup: This class acts as a linker between all the various drag and drop enabled DragComponent. It provides methods for ensuring only one component is the drop target, showing extra user feedback, and maintains a single point of focus. Moreover it provides a storage space for necessary shared variables such as mouse_offset of initial drag etc.
• XORToggleButtonGroup: Just like any other button group, this object encapsulates several checkbox listeners, but instead of recording which are selected, or indeed what buttons it has assigned to it, this group has but one purpose: to ensure that at least one check button is always selected.
• MED: Determines the MED between two metadata element names. Adapted from code by Michael Gilleland, Merriam Park Software, as detailed in a short essay called "Levenshtein Distance, in Three Flavors" available at http://www.merriampark.com/ld.htm.
• TreeSynchronizer: My latest diabolical class synchronizes the expansion state of two or more JTrees. Muh-hahahaha. Note that these tree should be based on the same model. If they aren't it won't work. So there.
• Codec: Provides a standard, extensible way to convert from one format of string to another (given that each format has differing requirements regarding legal characters and escaped characters)
• HTMLStringTokenizer: This class functions much like a StringTokenizer in that it tokenizes a long string into tokens, however this tokenizer cleverly notices HTML formatting tags.
• HashMap3D: Provides a HashMap implementation that indexes by two keys. Perfect for the storage of metadata references based on their metadata element and assigned value.
• ArrayTools: This utility class contains a series of static methods for common array type manipulations including appending, casting and changing between containers.
• Generator: Automatically generates html help documents given an input text file using markup and a template defining what the markup means.
• ExclusiveListSelectionListener: This listener is used to ensure that in a group of JList or similar components, only one list actually has elements selected.
• GURL: Extends the standard URL class to include several new data elements and the ability to take a string and parse a valid url.
• FocusChangerTask: Create one of these to shift the gui focus as necessary. Will not run until the specified component is visible.
• EmailAddress: This class wraps an email address, separating address and host, and providing a pretty printer.

Home | Contact Us | Privacy Policy | Terms of Service