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

The pageblocks framework includes the following categories and quantities of custom tags, custom types, and integral include files.

Actn - 15
API - 29
Auth - 3
Cnfg - 14
Date - 19
Err - 13
File - 7
GIS - 3
Gui - 13
Img - 16
Log - 5
Num - 6
Page - 17
Srch - 3
Str - 20
Util - 3

Philosophical Attributes

Maybe software design has always been coupled to philosopical approaches, but today it certainly seems the vogue thing to have a "philosophy" behind your software. The philosophy behind PageBlocks was simple: make the code do as much work as possible for me.

Seriously though, after doing web programming for a little while it was abundantly clear there was a lot of repetitive code and a lot of interaction between systems that I was spelling out manually. I was doing all the work, and the code was pretty stupid. This wasn't good.

I had written much smarter stuff than this before, so it was time to take a systematic approach to web site code. Instinctively I knew I wanted to use convention to automate processes, and use configuration (or perhaps it's more accurate to call it meta programming) to automate code generation. I wanted systems in the application to figure things out on their own, and I wanted to use simple text files that would require much less debugging than the equivalent amount of code. I also wanted standardized systems for error handling, user authorization, logging, and other systems which should be included in every web site.

The PageBlocks framework has evolved gradually as time has permitted and as I have elevated my own education about modern software. I've pushed forward with an idea just to backtrack a little and reorganize, but with each version it has provided more tools and gotten smoother to work with.

Today, the overall page assembly process is procedural. It could be object-oriented, but being that it is already automated it wouldn't change how the developer codes anything, and I've yet to believe the OOP overhead is worth it for this particular system given the way Lasso works as a page-oriented language. Most other support systems such as error-management, data and rules validations, user management, and data modeling are now object-oriented. Some procedural and sophmoric OOP warts still exist, but a few refining releases will gradually get rid of those.

Conventions

Providing standardized tools to work with means having standardized conventions to develop with. The PageBlocks framework, by its very nature of being a framework, defines many application coding conventions. Certain file naming conventions for content files is what makes the page assembly automation work, certain site organization and environment variable conventions makes code reusable in projects and sharable amongst developers.

However, with all of the structured standards in the PageBlocks framework, there is a conscious effort to remain artistically flexible. The mixture of so-called stub file and onefile pages is supported, as are real and virtual URLs, and while site structure is standardized through a virtual representation, the actual folder naming and organization of a site is developer controlled. These and other areas allow developers to work in their own style while still taking advantage of the framework's capabilities.

Next Steps

Overall, I'd say more refactoring towards object oriented code, and towards more standard patterns where they make sense. Most of the internal systems are interdependent. While I generally consider this a good thing in that in enables deeper automation, I suppose it might be time to start looking at abstracting those couplings and allow the various systems to be more independent outside of the whole framework. So that will likely happen in future releases.