Archive 1.x:Anatomy of a Page Template File

Here are some example templates:


 * Sample Chart Template
 * Sample Image Template
 * Sample Topic Template
 * Sample WebMap Template
 * Sample Stories Template
 * Sample Multi-component Template.

Synchronizing with the Drupal Content Type
A layout is an aggregation of a series of pages dedicated to support a certain CCK content type. Most of the pages accessible in what we call a "layout" shares the same CCK content type (except for a few exceptions depending on the usecase). For example, the "map" layout section is populated of a series of "map" content types.

That custom "map" content type defines a few custom CCK fields that are used to setup a specific page of the layout. In the case of the "map" layout, it may be a new custom field that, for example, lets people pre-load markers and polygons on the webmap.

Each of the content types used to populate each of these layouts have their own template page in the theme. These content type template pages are defined in each theme folder, and looks like " " where "map" is the name of the content type to skin.

Basic Layout
The basic layout of a template is generally inherited from the main node template. The same overall layout is generally used, except that the body of the page will be filled with the information related to the layout to skin.

Specifying structWSF Queries
Depending on the layout, information about different records, from different datasets, may be needed to properly display the desired information on a layout page. All of this information is queried to the running structWSF instance. All the web services can be queried, but generally the developer will query one of these endpoints:


 * 1) Search
 * 2) Crud: Read
 * 3) SPARQL

depending on the information it needs to populate the layout page.

Incorporating External Applications and Semantic Components
Sometimes external libraries may need to be employed to display information about the record(s). These external applications may be other JavaScript tools, or semantic components.

Once the structWSF endpoints get properly queried, the developer will have to create the data structure that feeds these external applications in order to display the information in these different applications.

Loading, using and feeding these external applications really depends on the application you want to use and is beyond the scope of this document.

Auto-completion
Sometimes, when you define the custom fields for your new custom content type, you may want to be able to perform auto-completion tasks to help the system administrator to know what to put in these custom fields (this particularly may happen when the value to put in one of these fields is a URI reference to a specific record from a specific dataset).

Such an auto completion task is possible by creating a special module (let's call it ) that is used to hook a node creation page, and to change its normal text fields into auto-completion text-fields.

When set up properly, such a module manages the different auto-completion fields, from each kind of layout content types. So, for a field A it will make sure that the dataset X is queried; for a field B it will make sure that the dataset Z is queried; etc.

Here is a working example of such a Drupal module:

Each time a new auto-completion field is created, the  function is updated to set up the auto-completion behavior of this field.

Because of the way this Drupal technique works, each time that this function gets updated to handle a new field, the  module has to be disabled, and then re-enabled. This will ensure that the Drupal hooks get properly created by Drupal.

Now, each time an administrator of the node proceeds to create or edit a content type, as soon as he will start typing into the auto-completion field, he will get results from a dataset, or a set of datasets, that comes from the Search structWSF web service endpoint.

Other Design Considerations
Like any other Drupal template file, it is possible to add standard HTML, other content, or style classes and ids anywhere else on the template page. Typically, of course, this includes calls to headers, footers and other standard layout or block components. See existing  files for examples.