Embedded Files
We following present you the explanation of the main objects of our tool and their interactions, for a better understanding of its underlying structure. In short, the main idea is the following: collectors, based on different extraction techniques, are able to create concepts or properties templates. Such templates will be further used for retrieving and instantiating a set of concrete Concepts with Properties. But such instances are, so far, simple objects with a few properties and minimal functionality, for example, for locating the associated element in a concrete DOM. So, in order to enhance and extend a Concept functionality, it needs to be wrapped with a proper ConceptDecorator, so the user eventually can interact with it through diverse modalities.
In this light, we first present collectors and how they can analyze and process an HTML element for abstracting and structuring concepts and properties templates. Then, we show how templates can be empowered with searching capabilities of the original concept's Web site, how they can produce their concepts instances, how those instances can be wrapped by decrators and be used for making it possible the user interaction, and finally, how such instances can be requested from WOPs to WOA.
1. Collectors of Materializable Templates
When our extension is asked to enable the current DOM elements selection, it basically performs two tasks: 1) it injects some style and behaviour to help the user visualize what is the currently pointed element by highlighting it, and 2) it attaches a new listener to the popupshowing sidebar's browser event and asks every collector to analyze the trigger node (the element the user right-clicked on) and to render a menu option for collecting it, if applicable.
In the following figure, we can appreciate that each collector must be capable of analyzing a target HTML element and, if applicable, of rendering a context-menu item with their description and associating some behavior to it, that is, creating a MaterializableTemplate subclass instance and offering the user with a user-interface for its configuration. Finally, collectors should be capable of instantiating a concrete template with the automatically extracted data and the user input.
2. Materializable Templates and Search Engines
Materializable templates have the resposability of gathering the required data for creating concepts and properties instances, given a combination of selected HTML elements and the configuration the user has chosen for them. If required, it should also be able to obtain more instances than the ones defined in the original DOM where the template was defined, filter them under certain filters and creiteria.
For example, the user can extend the ConceptTemplate with a MicrodataBasedConceptCollector for picking an element in the DOM and define a concept from it, by automatically extracting the attributes associated to Microdata (itemscope, itemtype, itemprop, etc.). Then, through an MicrodataBasedPropertyColletor, he can define some properties and associate it to the created concept template.
At this point, we have the required data for locating the chosen HTML elements and instantiate the materializables −both concepts and properties−, but if you need to retrieve more instances that can not be found in the current DOM, you must configure a search engine. This one will offer the user with a contextual menu that wil allow collecting −with a similar mechanism the user performed the Materializables harvesting− and defining certain elements of the DOM as needed to simulate a search. When you use a search engine on a site, you usually have to enter some keywords, then you click a search button, you choose among a set of filters, and finally you start navitating the results through the pages. WOA needs a reference for locating those fields in the document, in order to emulate a search when the user ask for more instances.
3. Materializables and decorators
When the user has defined a template and asks WOA for the instances, a set of Concept instances is obtained. A Concept also has some similar properties to its related template, but with their own concrete values. For intance, while the template's xpath could be .//div[@id="gs_ccl"]/a, the materializable one could be .//div[@id="gs_ccl"]/a[2].
Every concept instance can be wrapped with −at least− one decorator. It will provide the concept with some specific behaviour and make it possible the user interaction. Some of these behaviour could require some properties of the concept to be defined outside its original context, and that is the reason for defining a URL for every property. For example, consider that you create a "Yahoo news" concept and you want to notify changes on the main entry of the site (through Reactive Web mechanisms) when you are browsing Google News site. You need to define a target location for the "Yahoo news" concept to be displayed in the "Google News" context.
As the power of the decorator pattern relies in adding -or changing- features from the combination of inheritance and composition, it is possible to easily extend the spectrum of supported specialized behavior for concepts, based not only on the available Concept methods but also in existing ConceptDecorator ones.
4. WOA
The WOA is the available bject for interaction with out extension through the WOPs. As it is instantiated at a privileged context as part of the extension, it has the capability of retrieving external content for materializing the concepts defined though a template, persisting data, etc. Developers can ask the WOA for a limited subset of concepts to be used in their scripts. It could be done by just retrieving the ones specified in the template or by asking the search engine to look for them under certain criteria and applying some filters. Finally, as WOA knows a set of decorators, they can also ask to wrap such subset with the specified decorator.
Page updated
Google Sites
Report abuse