Tour Sections

• Introduction
• Site Structure
• Page Assembly
• URL Handlers
• Multi-View Strings
• Authentication
• Database
• Error Handling
• Validation
• Config Data
• Logging
• EDP
• User Interface
• Formatters
• Images
• API Utilities
• Developer Tools

ToolKit Description

Site Structure

The PageBlocks framework uses a standardized approach to application structure in order to relieve the developer of many setup details. However, that structure is acheived through abstraction which allows the implementation to vary while the programming idioms remain constant. Application structure is broken into four primary components: 1) the API libraries which are typically run from /LassoStartup, 2) a small set of API files in the application code, 3) site resources, and 4) site section or module resources.

The application core files are things which the framework requires, but can be modified to suit the application's specific needs. This includes some initilization files which declare site-wide variables, and some files that support the page templates.

Site resources tend to be those that govern the look and feel of the entire web site such as its masthead graphics, style sheets, general media assets, and any logic libraries with site-wide scope. A site may be developed as a monolithic application where all resources are stored as site resources, or as a modular application with distributed resources.

Each site section (i.e. company, products, support, or other such site divisions) can be structured to be a self-contained modular unit. It is not self-sufficient in that it requires access to the core API (which is not redundantly stored within the module), but it is self-contained in that all resources unique to that module such as logic, media assets, data structures, page layouts, and administration functionality are stored within a single folder. This folder can be dropped into another pageblocks site and expected to function with little modification while adopting the site's masthead, styles, and other site-level resources.

The modular capability is important to some sites, and not at all important to others. If you're a captive developer working on a single corporate site, the monolithic approach is likely the easiest to work with. If you're a freelance developer and find yourself frequently needing to deliver a News section for your projects, then a modular News solution can be a very productive approach.

You might be concerned that the above illustration means your files must be organized in this manner. Not so. There are two ctypes which use instance variables to define the location of resources. The object $fw_sPath defines the actual paths for site resources and $fw_mPath defines the relative locations of module paths. These objects can be redefined and extended as needed. By using these objects for path references like ($fw_gPath->'configs') one developer's code will work in another developer's site even if the folder structures are totally different.