As advanced user, you can perform the following stuff:
Extending Collectors requires to define a new AbstractCollector subclass. Consider a scenario where you want to support the template creation from MicroData attributes embedded in the HTML elements of the current Web page. So, first we need to validate that an element has defined such attributes. Consider the following piece of code:
As you can see, you should be particularly interested in the itemscope and itemtype Microdata attributes for a MicrodataConceptTemplate, and in itemscope, itemtype and itemprop for the MicrodataPropertyTemplate. So, you should implement the analyzeDomElement behaviour as a template method of MicrodataCollector class, and override it in MicrodataPropertyTemplate:
Then, you should extend the class. Let's say with a MicrodataConceptCollector subclass:
You need to define the renderMenuItemFrom method, for making the Collector visible for user interaction. It's as simple as calling the renderMenuItem method with an id for the item, a label (user readable string), a parent menu to be added (ui.conceptsMenu or ui.conceptsMenu), and a callback function.
Then, you need to process the extracted data. You can use an API for interpreting the microdata attributes, you can request the referenced element in itemtype, or you can simply analyze the DOM element. In this example, for simplicity and agility, we merely interpret the name by analyzing the string. You need to implement all this related extraction mechanism when loading the concept-creation form, by implementing the loadMaterializableOptions method where you will receive a ui instance that let you easily obtain some user interface related elements. E.g. you can easily obtain the sidebar document for manipulating the existing interface (name, tag inputs, title label, xpath options) or adding new elements to it.
That is all you need to define, because saving a concept is the same in all cases; the only difference relies in how much of the required data we can infer instead the user. While you save a concept, as you can see in the following snippet, the collector should be capable of generating the materializable object so it can be stored in the WOA database.
Implementing that is as simple as returning a JSON with the values entered in the form. It is mandatory to use a JSON object because it will be serialized for communicating it through the ports of the extension. If you need a final extra processing of the data, you can override the getMaterializable method.
Finally, take into account that the allowed tags for concepts are the labels of the entities defined in http://dbpedia.org/ontology/ (see this example) and the ones for properties are the related ones (see this query example).
A decorator is responsible for adding behavior to the concept. If you want to create your own decorator for supporting some functionality not covered by the decorators provided by WOA, you extend any of them, as the one we present below:
Suppose you want to extend the AbstractDecorator superclass. You should define a new class, as we did with GenericDecorator, and define some tags that make it possible for WOA to find and retrieve the decorator. You should also implement as a function every message you want to expose to the user, and then include each of the method names in the array that is retured by the getMessages method. The elements of such array are objects with not only the name of the method, but also an id, some required properties (if it applies) and showInUi with a boolean value, that allow WOA to know if it should be exposed to the user.
It is important to note that you can implement the class methods by using prototype, but the instance methods must not be implemented this way, because this way it is not possible to clone them through contexts (e.g. from the extension environment to the sidebar or current Web page's document).
Importing your own application is a very flexible option, since it lets you create a Web application with no restrictions on what kind of resources can be used; the same rules as the ones for a regular Web application are applied. The only requirements are:
1. to start using WOA library when the extension has sucesfully loaded the WOA object in the context of the application document, that is, defining a initWoaScript function that will be called by the extension when everything is ready.
2. to create a file in the root folder named "package.json", wich contains the manifest data for your application. The required attributes are: a) id, to be used as the namespace, b) name, to be displayed in the apps management and c) index, to specify and load the main entry file. It could look like this one:
Then, you have to import the application into WOA. Follow these steps: