How It Works

When responding to any visitor request, Odin Assemble works with three types of "blocks." "Blocks" are combined and passed to an "assembly" phase. After "assembly" has been completed, based on configuration, Odin Assemble can evaluate and process the assembled response. The results are then returned to the visitor making the original request.

To successfully respond to any visitor request, Odin Assemble must have at least two valid blocks (page and template).

Blocks

"Blocks" can be broken into three groups. Each "block" type has a corresponding physical directory one level deeper then the Odin Assemble handler.

1. Pages
   • Pages represent the real "content" of your web-site and are stored in easy to edit HTML. Page "blocks" would be stored in /pages. Page "blocks" always end with a .html extension.
2. Templates
   • Templates represent the "design" or "look and feel" of your web-site and are stored in easy to edit HTML. Odin Assemble can render robust web-sites using a multiple templates or a single template minimizing the "design" overhead of any project. Template "blocks" would be stored in /templates. Template "blocks" always end with a .html extension.
3. Elements
   • Elements represent the "logic" of your web-site and are stored either as easy to edit HTML or PHP scripts. Using HTML based can save time by centralizing consistent HTML elements of your web-site such as your navigation or footer. Using PHP based elements the creative uses for Odin Assemble are almost limitless. Element "blocks" would be stored in /elements. Element "blocks" can end with either a .html or .php extension.

Assembly

When a user makes a request, Odin Assemble uses the active "blocks" to assemble or render the response. Assembly occurs as follows:

1. Identify the requested page block
   • If the requested page block is missing, the user will receive a graceful 404 error,
   • If the page block is identified, continue to step 2.
2. Identify the requested template block
   • If the requested template block is missing, Odin Assemble will attempt to use the default index.html level template. If no template is available, the user will receive a graceful 404 error.
   • If the template block is identified, continue to step 3.
3. Element block read-ahead
   • Using the a combination of the requested page and template blocks, Odin Assemble identifies any valid element references.
   • If any element blocks are identified, Odin Assemble will interpolate execute any PHP based elements and if no PHP based elements are found, Odin Assemble will look for basic HTML elements. Regardless of type found, if the reference matches the filename sans extension (.html or .php) it will be process and interpolated.

Post Evaluation Processes

Similar to many content management systems, Odin Assemble offers an optional post process phase. Currently this post processing phase is limited to a single function.

1. Meta Data Generation
   • Odin Assemble currently offers two forms of meta data generation, frequency based and contextual.
     • Frequency based generation uses the keyword functions from Odin Organic Framework to provide fast and accurate keyword generation. Using the HTML entities surrounding the page text a weighted frequency is calculated for single terms, doubles and triples. Common "stop" words as well as "avoid as single" words are stripped and the resulting singles, doubles and triples are merged into a final list of keywords.
     • Contextual generation uses the Yahoo! Developer Network Content Analysis system. Using the Yahoo based contextual generation requires a valid Yahoo developer key and a pre-defined web-site "context" value in your Odin Assemble configuration.

Using the keywords and terms, Odin Assemble then builds both page level meta keywords and a valid page level meta description.