Phosphorus and Lime
A Developer's Broadsheet
This blog has been deprecated. Please visit my new blog at klenwell.com/press.
profile
Name: klenwell
Home: San Diego, California, United States
About Me: designer, programmer, wordsmith
Friday, January 27, 2006
PHP: Page Framework
Since shortly after I started seriously scripting in PHP -- nearly 18 months ago now -- I began to put together my own framework. It started rather unsystematically as a function of necessity but soon became more formalized and structure. It had three main goals:
1. Be reusable
2. Be portable
3. Be versatile but not too bloated
A fourth goal might be: be as intuitive and as neatly formatted as possible.
The biggest challenge was figuring out how to automatically set root paths so that changing the level of the root project directory between servers would not break assocations with include files.
About 3 months ago, I arrived at something that I feel meets the goals above. It's a continual work in project, but it's stable (I can make changes and additions without having to refactor major parts of my library) and it works. It's still a bit idiosyncratic, but more intuitive I suspect than a lot of the more complex frameworks out there, and I continue to work at making it more elegant.
The one glaring problem I still face, however, is developing a clean, logical framework for individual pages. The ideal framework, I suppose, would load template from one master controller index.php file. I don't want that. But I want to organize my scripted web page files around a limited number of functions: most fundamentally, input pages (forms) and output pages (views -- like a search results page.)
I've been giving a lot of thought to the issue of page frameworks recently and I finally came up with something this week that satisfies the goals above and I hope won't need to be significantly revised in the future. It's designed to work with my more general site/project framework, but the underlying concept I believe is broadly applicable.
Here are the major components -- they could also be called modules, or simply sections -- of my framework. These are fundamental things that I figure every dynamic web page requires:
// *** File Overview (Documentation)
// *** Driver (Core Path Declaration and Includes)
// *** Variable Declarations
/* PHP is loose with this but I try to be as exact as possible) */
// *** Access Module
/* What data must be provided (e.g. authentication data) for page to be processed */
// *** Event Module
/* This consists of two parts -- a controller section and a case section. The controller section set boolean trigger variables ($_TRIGGER['event'] = TRUE;) based on the data submitted to the page (by say a user form or a referring page). The case section is then a series of short routines or includes that are wrapped in IF statements conditioned by whether the trigger is TRUE or FALSE. These IF blocks will generally flip another boolean flag -- a show flag ($_SHOW['panel'] = TRUE;) that dictates in the next section what heredocs get displayed in the page. */
// *** Output Module
/* A series of heredocs -- really subtemplates -- that get set according to their show flag. They're termed panels and make up an array: $_PANEL['heredoc'] = <<<HEREDOC... These should all be declared as empty strings above. */
// *** Template
/* The basic page template. Where the heredocs are echoed. */
// *** Postscript
/* Where other scripts (like a database update or an email dispatch) can be run in the background after the (buffered) template has been flushed. */
I'll post my actual template sometime in the future after doing a little more real-world refinement on it.
1. Be reusable
2. Be portable
3. Be versatile but not too bloated
A fourth goal might be: be as intuitive and as neatly formatted as possible.
The biggest challenge was figuring out how to automatically set root paths so that changing the level of the root project directory between servers would not break assocations with include files.
About 3 months ago, I arrived at something that I feel meets the goals above. It's a continual work in project, but it's stable (I can make changes and additions without having to refactor major parts of my library) and it works. It's still a bit idiosyncratic, but more intuitive I suspect than a lot of the more complex frameworks out there, and I continue to work at making it more elegant.
The one glaring problem I still face, however, is developing a clean, logical framework for individual pages. The ideal framework, I suppose, would load template from one master controller index.php file. I don't want that. But I want to organize my scripted web page files around a limited number of functions: most fundamentally, input pages (forms) and output pages (views -- like a search results page.)
I've been giving a lot of thought to the issue of page frameworks recently and I finally came up with something this week that satisfies the goals above and I hope won't need to be significantly revised in the future. It's designed to work with my more general site/project framework, but the underlying concept I believe is broadly applicable.
Here are the major components -- they could also be called modules, or simply sections -- of my framework. These are fundamental things that I figure every dynamic web page requires:
// *** File Overview (Documentation)
// *** Driver (Core Path Declaration and Includes)
// *** Variable Declarations
/* PHP is loose with this but I try to be as exact as possible) */
// *** Access Module
/* What data must be provided (e.g. authentication data) for page to be processed */
// *** Event Module
/* This consists of two parts -- a controller section and a case section. The controller section set boolean trigger variables ($_TRIGGER['event'] = TRUE;) based on the data submitted to the page (by say a user form or a referring page). The case section is then a series of short routines or includes that are wrapped in IF statements conditioned by whether the trigger is TRUE or FALSE. These IF blocks will generally flip another boolean flag -- a show flag ($_SHOW['panel'] = TRUE;) that dictates in the next section what heredocs get displayed in the page. */
// *** Output Module
/* A series of heredocs -- really subtemplates -- that get set according to their show flag. They're termed panels and make up an array: $_PANEL['heredoc'] = <<<HEREDOC... These should all be declared as empty strings above. */
// *** Template
/* The basic page template. Where the heredocs are echoed. */
// *** Postscript
/* Where other scripts (like a database update or an email dispatch) can be run in the background after the (buffered) template has been flushed. */
I'll post my actual template sometime in the future after doing a little more real-world refinement on it.
some rights reserved, © 2006