Slooze

Home | Description | Usage | Design | FAQ | Demo

Design

This document gives an overview of the architecture of Slooze. It is not intended to be comprehensive or definitive in detail - read the code for that. It is intended to provide a general overview via diagrams and pictures that cannot be included in the code as comments.

Database schema

The schema is designed with simplicity in mind, but also future extension. Possibilities for extension in future releases included adding fields to the Roll table (for example, a description, an opportunity to describe the film, camera, etc.), and adding further fields to the Pictures table (for example, date and time).

Object model

The main class is Slooze. To use Slooze, a single object of this class is instantiated. There are several public properties (variables) that can be set, and two public functions that may be called to validate inputs and render a page. All the other functions are private to the class.

A Slooze object makes use of an internal object variable that acts as a container for the picture metadata. This may be SloozeCtCsv, an object that uses the services of an underlying Csv object to store the metadata in comma separated text files, or SloozeCtSql, an object that uses the DB_Sql database abstraction class from PHPLib to store the metadata in an RDBMS.

Note that this is a simplification. For each of the objects, slooze_local.php defines a My... extension of that object. This allows:

Slooze class

The following describes the higher-level functions of the Slooze class.

validateInputs

validateInputs attempts to find input variables in the global GET and POST arrays, sanitises them, and returns the result as an array suitable for passing to renderPage.

renderPage()

renderPage() is the main public function. It renders one of several different types of pages depending on the variables that are passed to it. renderPage() calls renderTopic(), renderPicture(), renderRoll() or renderSearch to do the work of actually rendering the required page.

renderPage() also calls handleAction() if necessary to handle actions that update the database.

renderTopic()

renderTopic() renders a page for a single topic. The page is built up from a number of smaller elements. These are rendered by a variety of show*() functions.

renderPicture()

renderPicture() renders a page for a single picture. The page is built up from a number of smaller elements. These are rendered by a variety of show*() functions.

renderSearch()

renderSearch() renders a page for a search result. The page is built up from a number of smaller elements. These are rendered by a variety of show*() functions.

renderRoll()

renderRoll() renders a page for a single roll. The page is built up from a number of smaller elements. These are rendered by a variety of show*() functions. This page is only shown in admin mode. Rolls are an internal organisation that are not seen by regular users - they navigate via topics.

handleAction

handleAction deals with POSTed forms that call for some update of the data. The reuired actions are simple enough to be handled directly within handleAction, with the exception of adding all pictures in a new roll. This is handled by addAllPictures.

addAllPictures

addAllPictures searches a given roll and attempts to find pictures that have not yet been added to the roll. When found, it adds them. The criteria for valid pictures are that the filename suffix matches that required for pictures but not that for thumbnails.

showForm...

If admin is TRUE, extra forms are shown at the end of each of the pages rendered by the render... functions to allow database updates. These forms are rendered by a variety of showForm...() functions, which in turn build the forms from individual elements provided by the showFormElement... functions.

URL schema

Slooze accepts all its input variables in one big associative array. Typically this array will be a cleaned-up version of HTTP_GET_VARS or HTTP_POST_VARS, generated by validateInputs() from variables passed in the URL or via a form.

For user pages, the variables are typically passed in the URL. There is no specific action instruction - Slooze decides what type of page to render based on which variables are present.

VariableValuePage rendered
TopicIDA valid TopicIDTopic
RollIDA valid RollIDRoll, unless FrameID is also present
FrameIDA valid FrameIDPicture, as long as RollID is also present
searchA search stringSearch results

Additionally, modifier variables may be present. These do not affect what type of page is rendered, but do affect how that page looks.

VariableValueEffect
sortviews | ratingsCauses thumbs in rendered page to be sorted

For admin forms, the variables are passed via the POST method. Slooze decides what action to take based on the action variable.

VariableValue
action addTopic | updateTopic | deleteTopic | addRoll | updateRoll | deleteRoll | addPicture | updatePicture | deletePicture addComment | deleteComment | addRating
TopicIDA valid TopicID
RollIDA valid RollID
FrameIDA valid FrameID
ParentTopicIDA valid TopicID
DescriptionA text description
SummaryA text summary
CommentA text comment
RatingA numeric rating -2..2

After taking the action, Slooze renders a page based on which variables are present, exactly as for user pages.


Powered by PHP Powered by PHPLib Licensed under the GNU GPL SourceForge Logo