TGcrud offers a rather different interface for saving information than Eclipse: Eclipse's storage system is based on a workspace containing named projects containing named files and folders, rather oriented on traditional file systems. TGcrud, however, maintains a set of objects described by a set of metadata (like authors, title etc.). Both can use URIs to identify files.
The plugins info.textgrid.lab.core.model and info.textgrid.lab.core.efs.tgcrud try to bridge the gap between both systems and to offer a convenient way for TextGridLab plugins to access both TextGridRep's objects and metadata.
We use three implementation layers to manage our objects:
TextGridObject
s. This layer is completely
implemented by TextGrid, and it is the layer clients like object
browsers or metadata editors usually talk with and which
commands and menu entries on TextGrid objects are usually
contributed to.IFile
s, IProject
s and other
IResource
s is the layer (content) editors
usually see. It is the standard way of interacting with files in
Eclipse, and it is completely implemented by Eclipse. Conversion between the layers works by using the adaptor pattern as provided by Eclipse. I.E., if you have a TextGridObject and need an IFile,
TextGridObject textGridObject; /* ... fill textGridObject ... */ IFile file = (IFile) textGridObject.getAdapter(IFile.class); if (file != null) /* do something with file */
or vice versa
IFile file; /* ... fill file ... */ TextGridObject textGridObject = (TextGridObject) file.getAdaptor(TextGridObject.class);
Everything in this section is subject to change / refactoring. Please always check with the implementation, and please always see the javadocs (which may be more detailed, anyway).
URI uri; /* get the object's URI somehow into uri */ TextGridObject object = TextGridObject.getInstance(uri, true);
This creates a new TextGridObject from a textgrid uri, calling
TGcrud#readMetadata if neccessary. If you set the last argument
to false
, the call to readMetadata may be delayed.
You need to pass in the metadata as an XML tree fragment hanging from an OMElement (that's AXIOMs element representation). The OMElement should contain the tgMetadataObject.
OMElement element; boolean complete; // if false, element contains only fragmentary metadata /* get some metadata into element */ TextGridObject object = TextGridObject.getInstance(element, complete);
If you create a TextGridObject from an XML fragment, there will be no immediate network access. This is especially useful if you create a lot of TextGridObjects at once (think search) and do not want a web service call for every single one. With the last argument (complete), you determine whether the metadata fragment you pass in is complete, i.e. it contains all the metadata TextGrid knows about for this TextGridRep object. If you specify false here and access a field not present in the metadata fragment at a later point in time, the object is finally completed by a call to TGcrud's readMetadata operation.
If your plugin somehow represents / contains a bunch of TextGrid
objects (e.g. search results or object browser), your objects (the
stuff you put in your StructuredSelections and/or that your
ContentProvider provides) must adapt to TextGridObjects (and they
should adapt to IFile, as well; once they have a TextGridObject
tgo they do so by forwarding the adaption request to
TextGridObject, i.e. return
tgo.getAdaptor(IFile.class)
).
Either your objects are PlatformObjects or IAdaptables and you provide an adaptor factory, or you simply put the TextGridObjects themselves in your selection/viewer.
See info.textgrid.lab.ui.core for an example