The context menus are automatically generated from the content structure which is defined in the XML Schema Definition (XSD). The screenshot below shows a piece of the XSD. The XSD contains all definitions for every element that's in the Shazzoo editor. In the screenshot you see for example the elements 'column3'  and 'textbox'. Both elements act as a container for other elements and that's where we insert the new Search component. The green arrows show you that the Search component has been inserted both in 'column3' and in 'textbox'. If we don't want the Search component to be positioned within a Textbox component, we can simply define it in this XSD.

We define the component also in the XSD. The screenshot below shows you a bit of the new search component definitions. Here you define the attributes of the component and things like data type, selectable values, default value, hide conditions, input validation, input translation etc..

We developed the <conditions> xml syntax ourselves. It supports the most complex AND/OR constructions. The JavaScript engine uses these conditions to produce valid HTML.

In the screenshot at the previous step we saw component attributes like 'search_engine', 'search_google_cseid', 'search_google_ads' etc.. and values like 'google', 'domino', 'bubblegum' etc. These attributes and values require labels to display in the component properties boxes. Shazzoo supports multi languages so these labels are defined in the applicable language XML file. Below you see a screenshot of the English language XML file.

Once a user inserts a search component in a web page the data for that search component is stored in an xml format like this:

We use an XML stylesheet (XSL) to translate this XML to XHTML when the page is served. Storing components data in an XML format offers important advantages:

• In case you want to modify the HTML for the component, modify the XSL and all components in your current web pages are up to date.
• Easy conversion to new (X)HTML standards like HTML5, just change the HTML output in the XSL.
• Extensive search and replace options.
• Extensive data exchange options with other (backend) systems. 

The screenshot below shows you the part of the XSL where our new search component is translated to the appropriate HTML.

At the previous step we used an XSL to translate XML data to XHTML. This XHTML includes classes which styles are controlled in a dedicated cascaded stylesheet (CSS).
The screenshot below shows you the part in the CSS where we defined the styles for our new search component.

Some components require JavaScript for interaction with the page visitor. This new search component for example requires a JavaScript to handle all data processing to and from the backend server when a page visitor performs a Domino full text search. After the visitor enters a query and clicks on 'Search', a JavaScript sends following XML package to the server:

A server script (see following step) processes the XML package and returns following response XML to the client where a JavaScript function translates the XML to XHTML.

The screenshot below shows some of the JavaScript functions created for the search component. This JavaScript library is available in every web page.

At the previous step XML was send to the server. A server script follows the instructions in the XML and returns a response XML to the browser client. You can find both send and return XML formats for the search component at the previous step.

Below two screenshots of server LotusScript that processes the XML and provides the browser client a response XML. No problem If the backend is not Domino. There will be another server scripting language that performs the same actions (i.e. PHP, ASP).