How it works
From Site Foundry
Contents |
How Site Foundry works
This is a brief guide to the rationale of how Site Foundry works.
URI resolution, rendering
The whole process of generating content within the Site Foundry application begins with rendering a page.
Each page is navigated to via a single URI, this is always checked to retrieve the correct page object (currently up to three levels). In this way, each page is created in its correct hierarchical position within the site (based on forward slash notation), and any additional items passed as wildcards to the resource within the params.
Page object model
Each page of site foundry is based around a page object model that makes up each component of the page. Therefore, these resources can be delivered in a variety of ways (eg XML) by changing headers and constituent templates. All this of course is handled by the Site Foundry core application.
Page object model construction
Very simply the page object is constructed as follows:
Array
(
[mime] => XML
[template] => templateName
[content] => Array
(
[area1] => Array
(
[resource] => resourceName
[template] => XMLTemplate
)
[area2] => Array
(
[resource] => pages
[template] => XMLarea
[content] => Array
(
[textArea] => Array
(
[pagesID] => 2
[tag] => 1
)
)
)
)
)
This array constructs each page, instantiating any resources assigned to build up the page, which will in turn render the required content based on the arguments passed to it.
Resource arguments
Arguments are passed to the resource at the time of instantiation by the page object. There are two types of arguments passed to each resource; these are as follows:
- Module arguments - from the page object
- Params - constructed from the browser URI
Of course the POST array can be accessed by any resource. It therefore stands to reason that only one module on a page can take into account the params and POST array, unless there is an application where several areas are going to respond back with different data based on the data passed via the same arguments.
Management
Management then of Site Foundry is based around manipulating this object to suit the needs of a website. Any type of module can be written to output any type of content, and placed at any point within page.
Templating
From the object above, it can be seen that each time one is rendered by the Site Foundry core; it is based around a template. These are created using Smarty – enabling designers to easily add in the Site Foundry variables to generate content entry areas.
A typical template would be as follows (items such as {$content.xxxx} are the Site Foundry Smarty variables):
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html>
<head>
<title>{$title_text}</title>
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
</head>
<body>
<div id=”wrapper”>
{$content.contentArea1}
<div id=”footer”>{$content.footer}</div>
</div>
</body
</html>
Each area can have any arbitrary name that will add meaning to the content entry workflow.
Additional template tags
The following tags can be added to templates to reflect the content items they represent:
- {$menu} - Places the main menu, and hence all pages included in the menu in manage templates.
- {$content.[area_name]} - A content area, where [area_name] represents a meaningful name within a template.
- {$m.[menu_name]} - A menu item created in the menu manager, where [menu_name] is the name of the menu.
The following tags can be placed within any pages module text area, and will be replaced by the relevant content item they represent:
- {domain} - The domain of the install, set by the FS_WWW value in the main config file.
- {[form_name]} - Used primarily for the inclusion of forms, where [form_name] is the title of a file located in the /forms folder. This can just be any text file used for popping in an item of content.
