A very simple accessor for hierarchies of images Stored in an XML file. More...
#include <CAcHierarchy.h>
Public Member Functions | |
CAcHierarchy (const CXMLElement &inConfiguration) | |
constructor opens a hierarchy file and reads it. | |
CIDRelevanceLevelPairList * | getChildren (const CPath &inID) const |
Gets a list of all children of an element. | |
void | addElement (TID inID, string inLocation, string inThumbnail) |
Adds an element to the collection. | |
void | push (TID inNode) |
pushes the node onto the stack | |
void | popNodeAndRegisterEdge () |
pops the node and registers the edge from new top to old top and back | |
operator bool () const | |
has this been successfully read? | |
![]() | |
virtual string | IDToURL (TID inID) const |
Translate a DocumentID to a URL (for output) | |
virtual pair< bool, CAccessorElement > | IDToAccessorElement (TID inID) const |
Translate a DocumentID to an accessor Element. | |
virtual pair< bool, TID > | URLToID (const string &inURL) const |
Translate an URL to its document ID. | |
void | getAllIDs (list< TID > &) const |
This is useful for making lists of which images are present in a database etc. | |
void | getAllAccessorElements (list< CAccessorElement > &) const |
List of triplets (ID,imageURL,thumbnailURL) of all the documents present in the inverted file. | |
void | getRandomIDs (list< TID > &, list< TID >::size_type) const |
get a given number of random AccessorElement's | |
void | getRandomAccessorElements (list< CAccessorElement > &outResult, list< CAccessorElement >::size_type inSize) const |
For drawing random sets. | |
int | size () const |
The number of images in this accessor. | |
![]() | |
virtual | ~CAccessor () |
virtual accessor for clean destruction | |
virtual CXMLElement * | prepareDatabase () |
If a new collection is created during runtime, this function prepares the indexing structures such that they are able to accept new objects. | |
virtual bool | isPreparedDatabase () const |
Is the database accessed by this accessor prepared? In other words: is there an index structure to access? |
Protected Types | |
typedef list< TID > | CPath |
In fact, because images can arise multiple times in the hierarchy, it is necessary to store the full path for each time the image arises in the tree. | |
typedef list< TID > | CChildren |
This class is there for mnemonic reasons only. | |
typedef map< CPath, CChildren > | CGraph |
The graph is represented as a map from path to children. |
Protected Member Functions | |
void | init (string inFileName) |
called immediately by the constructor, this function does the main construction work. | |
void | addEdge (const CPath &inFather, TID inSon) |
adds an edge from father to son and an edge from son to father |
Protected Attributes | |
CMutex | mMutexHierarchy |
mutual exclude for multithreading | |
bool | isOK |
is this well constructed ? | |
CPath | mNodeStack |
A stack of the nodes visited when building the hierarchy. | |
CGraph | mEdges |
Edges: The edges from father to son. | |
![]() | |
string_TID_map | mURLToID |
map the url of an image to the id of this image | |
TID_CAccessorElement_map | mIDToAccessorElement |
maps the ID of an image to the URL of this image |
A very simple accessor for hierarchies of images Stored in an XML file.
This was intended as the ultra simple example system for the browser benchmarking paper. It performed too bad in our benchmark to be taken seriously.
Currently I see the use of this as the base for systems, where the author knows how to generate a hierarchy of images, but the author fears the overhead needed for including his/her system into the gift.
Please note that IDs must start at 1 (ONE!!!).
|
protected |
This class is there for mnemonic reasons only.
Evidently it has the same type as CPath, however it designates a list of children.
|
protected |
The graph is represented as a map from path to children.
|
protected |
In fact, because images can arise multiple times in the hierarchy, it is necessary to store the full path for each time the image arises in the tree.
We base this on the idea that in each selection, each image will arise at most once. As a consequence, lists of selected images must be sufficient to define the path from the hierarchy's root to a given node or leaf of the hierarchy.
CAcHierarchy::CAcHierarchy | ( | const CXMLElement & | inConfiguration | ) |
constructor opens a hierarchy file and reads it.
Like every accessor, this accessor takes a <collection> MRML element as input (
cui-base-dir: the base directory containing the following file: cui-hierarchy-file-location: an xml file containing the hierarchy that you can browse using this accessor.
CIDRelevanceLevelPairList* CAcHierarchy::getChildren | ( | const CPath & | inID | ) | const |
Gets a list of all children of an element.
As it was said before, an element of the hierarchy is well described by a path in the tree, from the root to this element.
|
protected |
called immediately by the constructor, this function does the main construction work.
Starts the xml parser for reading the hierarchy file etc.
void CAcHierarchy::popNodeAndRegisterEdge | ( | ) |
pops the node and registers the edge from new top to old top and back
void CAcHierarchy::push | ( | TID | inNode | ) |
pushes the node onto the stack
|
protected |
Edges: The edges from father to son.
The edges from son to father are not needed, because it means simply popping from the path.