Introduction to egooge Services
In egooge, content is stored as XML documents. The schema for these documents is defined using XSD's.
Any number of XSD can be uploaded to the system. Once and XSD is uploaded, the type represented by the XSD becomes available in the editor to create new documents. The editor uses the schema to build a form dynamically.
Click here to open the content browser. Using the content browser, open the folder ‘schema” on the left hand side to see the list of schemas in this site.
Besides the standard entity types supported in XSD's (string, dates, numbers) egooge supports an extensible type system that allows a JavaScript developer to incorporate custom UI logic for new types. Custom types are marked in the XSD using attributes.
Click here to view the internal representation of sample schema called SectionDescription.xsd.
Click here to view and instance document that conforms to the SectionDescription.xsd schema.
To open this sample document in the content editor, first open the content browser and then open the folder ‘department’ and click one of the documents on the center pane and then click on the editor tab.
The names of folders and documents shown are all specific to this sample site. Different sites will contain different folders and document structures depending on the web sites data model.
The XSD supported can't have more than two levels of complex types. For example, a car XSD can contain multiple complex types but each one of these types can't have nested complex types. Although these is supported in XSD's it makes creating and most importantly using content editors a very difficult and confusing experience.
In egooge complex documents are created by combining multiple simple documents. Documents are combined by linking them together. These can be accomplished by adding a field to the document that references another document. Egooge recognizes these links and tracks the dependencies. These in turn allows egooge to maintain RI and allows editors to determine which pieces of content are dependent.
In this example, you can see a field called SectionDescription that keeps a reference to another document. In the XSD that defines the parent document the attribute egooge:handler=“include” indicates that this is a reference to another document. The system uses this information to update internal tables to track dependencies and enforce referential integrity rules.
Rendering:
The final representation for end users is created using XSL transformations. The pipeline that produces the final output starts in the front end server where the system first determines which device (the output format, mobile, browser, text, etc) will be used. Once the device is determined, a request is sent to a transformation service to produce the representation of a given document in a given format (device). The service selects the XSL based on the device, document type and the site the document belongs to. If the XSL is not defined on a sub domain, the system looks up on the parent domain. This allows sub domain to reuse/overwrite XSL transforms are needed.
Once the XSL if selected, the service applies the XSL and returns the content to the front end server.
Example:
To generate the HTML representation of this document: http://health.egooge.com/source/Harpo/DietAndFitness/TimelineOfATummy
The system is using the XSL template stored under /templates/HTML/story.xsd
http://health.egooge.com/templates/html/story.xslt?device=XML
To facilitate A/B testing scenarios a mechanism exists to modify the template selection logic.
To see this working follow this steps:
1. Click here to open an example of a collection rendered using the standard template.
2. Open this form and in the first field enter HTML/A, to select the ‘A’ version and submit the form.
3. Click here to open the same collection. Notice the layout has changed.
In this scenario, the cookie is forcing the system to first look for a template under the folder/template/html/A. If the template is not there they system will walk up the tree until it finds it. This mechanism makes it very simple to overwrite the logic for specific templates.
Queries:
Documents are indexed using the content index service. The content index service is independent of the storage system. It accepts requests for indexing documents and answer simple queries that have the form: tag1 [and|or] tag2 [and|or] … tagi
Queries can be defined in a document as in this example: http://health.egooge.com/queries/myQuery
It is also possible to modify the query parameters via URL parameters as shown here:
http://health.egooge.com/queries/myQuery?q=fire