Page Blocks

Hosting sponsored by:

Point In Space

ToolKit Description

Page Assembly

The PageBlocks framework is predesigned to automate several flexible methods of creating pages and retrieving content. These methods can be used exclusively or intermixed on a page by page basis to best suit the application needs. By adhering to the framework standards, the programmer's tasks remain focused on the content.

Corral Method

The PageBlocks framework began life based upon The Corral Method white paper by Peter Bethke which introduced a page building system of nested configurations and layout templates to the Lasso community. Though the mechanisms have evolved, anyone who has read The Corral Method and built sites using its ideas will find the essentials of the PageBlocks framework to be familiar. SiteConfig has been replaced by a single tag which executes a standardized sequence of tasks, but the idea of site-wide configuration details being performed prior to including a template which then includes content by its layout pieces is pretty much the same, with the major exception that many of the page by page var declarations and include statements required in by the Corral Method have been eliminated through automation.

Literal and Abstracted URLs

Pages served by the PageBlocks framework can respond to literal or abstracted URLs. Literal URLs like /products/widgets.lasso correlate to a real disk file path of the same hierarchy to a literal file named widgets.lasso which is used to set page-specific configuration details and invoke a specific page template. Abstracted URLs at a minimum use extensionless file requests that correlate to an identical disk path, but there is no file exists

pages use a centralized system to houses multiple page definitions in a single configuration file named _pageConfig.lgc. In the PageBlocks framework, there is typically one _pageConfig.lgc file for each module of the site. The use of these methods is not exclusive. The programmer may arbitrarily develop each page within any site module using any method.

Virtual pages support standard extensioned or extensionless page URLs like you see on this site. This uses nothing more than configuring the HTTP server to send extensionless requests to Lasso. The framework handles it from there.

Separation of Logic and Presentation

Following n-tier practices, application logic and content code specific to any page should be completely separated. This can be acheived by consolidating overall page logic into one file, or on a block-by-block basis. PageBlocks will automatically find and execute each logic and display source in order.

Pages are automatically assembled from files following a structured naming scheme linked to the template layout. Each template area intended to display content is assigned a name. These areas are called page blocks. A template might have "left," "main," and "right" page blocks. All block names are arbitrary and can be named according to location, function, or design features. For a page /products/widgets built with this template, the PageBlocks page loading framework would search for the files widgets_left.dsp, widgets_main.dsp, and widgets_right.dsp to load content into the respective page blocks.

If we revisit the example from above, to facilitate the separation of logic and display code, the PageBlocks page loading framework would actually load widgets_left.lgc before loading widgets_left.dsp into the left page block. Likewise for each page block in the template. Each of the files is optional, and the page loader will simply skip files it does not find.

There are actually several possible sources for both logic and display code to allow for pre-processing and post-processing to surround main process or display actions.

Page Assembly Details

The flow chart below illustrates the essential elements of the page building process.

Each page begins with an internal call to atBegin which after deciding how to handle the request, usually results in a call to fwpPage_init which is similar to an MVC front controller, and similar in concept to the Corral siteConfig. fwpPage_init performs many tasks, but we'll focus on a few essentials for this discussion.

First, if the site has been configured to use this capability, fwpPage_init includes a file called _initProfile.lgc. If you have a site which runs a custom subdomain for each customer, or perhaps runs a custom appearance for each customer or registered user, then as early as possible in the page initialization we may need some data regarding that customer's unique profile. Therefore, the _initProfile file would be used to pull configuration or style data preferences from a database. If this profiling is not necessary, then no _initProfile file is required, and this step is skipped.

Second, fwpPage_init looks for a _pageConfig.lgc file which can reside in the app root or within each major module root (i.e. /products/, /customers/, and that type of thing). The essential code in a _pageConfig looks like this:

$fw_pgAuthRequired = false;

select: $fw_myURL->'page';
case:'home';
  $fw_pgTitle = 'My Home Page';
  $fw_pgTemplate = '2colwn';
case:'aboutus';
  $fw_pgTitle = 'About Us';
  $fw_pgTemplate = '3col';
case:'login';
  $fw_pgTitle = 'Admin Login';
  $fw_pgTemplate = '1col';
case:'appStatus';
  $fw_pgTitle = 'Application Status';
  $fw_pgTemplate = '2colwn';
  $fw_pgAuthRequired = true;
  $fw_pgPrivilege = 'fw_user->prvlg.usrs_view';
  // user object $fw_user must have
  // an allowed prvlg property of 'usrs_view'
case;
  $fw_pgTitle = 'Page Not Found';
  $fw_pgTemplate = 'nopage';
/select;

There are several additional features to use, but the gist is that {file_pageConfig} is where the basic vars are declared that are important to driving the page template and overall page assembly process. This is not where you define the gajillion vars you need for the whole page.

The third step in the process is that the fwpPage_init call ends up with the first format file include in the page assembly process by calling fwpPage_loadTemplate (a.k.a. the templateLoader). The templateLoader has the opportunity to load an optional logic file that affects the whole page even before the template itself is included. This gives the page-level logic file a chance to influence the nature of the template if needed. With this file, you can pull page-generic CMS content if applicable, or do pretty much whatever you want to. After the page-level logic is loaded (if available), the HTML page template is loaded. A page template is just a structural shell for the main layout blocks, and if using table-less CSS could look something like this:

[// the page head is set apart in a reusable file ]
[include: ($fw_gPath->'apiLibs') + 'fwpPage_templateHead.lgc']
<body> 
  <!-- 2colwn' -->
  <div id="pagewrapper">
    <div id="pgblockhdr">
      [include: ($fw_sPath->'headers') + $fw_pgHeader]
    </div> <!-- /pgblockhdr -->
    <div id="pgblockbody">
      <div id="pgblock2colnwleft">
        [fwpPage_loadBlock: 'left']
      </div> <!-- /pgblock2colnwleft -->
      <div id="pgblock2colnwmain">
        [fwpPage_loadBlock: 'main']
      </div> <!-- /pgblock2colnwmain -->
    </div> <!-- /pageblockbody -->
    <div id="pgblockftr">
      [include: ($fw_sPath->'footers') + $fw_pgFooter]
    </div> <!-- /pgblockftr -->
  </div> <!-- /pagewrapper -->
</body>
</html>

Of course, the developer is in complete control as to what that template is and how it is written (CSS, tables, etc), but the key feature to notice is the fwpPage_loadBlock tag (a.k.a. the blockLoader) Each template has one or more page blocks which are regions of content.

The blockLoader call automates a process of embedding a variety of possible include files into each page block, though, typically, each page block may contain a chunk of logic and/or a chunk of display content.

If we use a page named 'home' and the template example from above, a typical pageBlock file set would be named home_main.lgc, home_main.dsp, home_left.lgc, and home_left.dsp. The .lgc files are for performing any logic applicable to that display block such as data queries, business logic, or whatever. The .dsp files are the HTML display files. You'll notice there's a structured naming convention for the files: pagename_blockname.fileType. This structure allows for the automation process that templateLoader and blockLoader perform.

There are many content fetching/creating options, and PageBlocks has been used to build many different types of sites and content systems using these basic bulding blocks. The above is just the basics.

Authenticated Pages

By now you're wondering about authenticated pages. You can refer to the Authentication section for details, but let's just have a quick look. One of those many things that fwpPage_init does, is the handling of authentication and authorization. The PageBlocks framework includes a sophisticated, yet easy to use, user management system. It takes a few lines of code to process an initial login submission, and after that, the framework handles creating a user data type which includes the user's permissions. Application code can tap into the user's profile data with something like this:

$fw_user->(getProfile:'userEmail')

or acquire a user's specfic permission attribute like this:

if: ($fw_user->(getPrivilege:'orders_view')) == fw_kAllowed;

There's even attributes to enforce data query filters based on the user's defined role in the application.

Suffice it to say that user authorization is well integrated into the framework, and very easy to apply at the page level, block level, or even single field level to control what each user can see and do.

Summary

With the PageBlocks framework, the developer focuses on the value-added steps of template design and content in easy-to-maintain discrete pieces. The framework automatically detects and uses new logic and content files added by the developer, and keeps user data at the ready for authorization needs.


© 2002-2012, pageblocks.org