I plan to use a directory for every module. Depending on module granularity, the site might get cluttered with files if all files are in the same place.
Yeah. I find I spend a lot of time working out an intuitive directory structure and var / fn names. Helps enormously in the long run.
For instance, a transaction class containing database functionality specific to the module can be called transactions.php.
Eclipse
http://www.students.cs.uu.nl/people/voo ... /index.php is worth a look for something ready-rolled - or just as an example of good OOP design. Working out your own is also a worthwhile exercise if you've got the time.
The RequestManager I understand. Can you provide an example of a block handler setting meta data? (not necessarily code. Please describe it.)
I think what you call BlockManagers are what is missing in my master plan.
BlockManger loads the objects used to create page vars for each page layout block. It's not tied to any particular page at all and so needs to be given a list of objects to load ($block_meta). This is defined in a RequestHandler (individual handlers per page type).
Block object meta data (I'm self-taught so I hope I'm using that term properly) is an array:
$block_meta[0]['script'] = 'path/to/file.php';
$block_meta[0]['class'] = 'MyClass';
$block_meta[1]['script'] = 'path/to/file2.php';
$block_meta[1]['class'] = 'MyClass2';
etc - an element for each block object to be loaded for this request.
BlockManager loops through the array loading each block object in order. Often the order isn't important - would only matter if block objects need to access each others vars (they can't access a var which hasn't yet been defined - obviously).
In BlockManager I use this to iterate through the array:
Code: Select all
<?php
function loadBlockScripts()
{
// array_shift returns null if array is empty or not an array
while(!is_null($block = array_shift($this->block_meta)))
{
include($block['script']);
${$block['class']} =& new $block['class']($this, $block);
${$block['class']}->setPageVars();
}
}
?>
Knocking an element off the array each loop allows you to do a neat trick: the block objects can redefine the $block_meta array while it is being processed by BlockManager - even reloading themselves for another go. I haven't actually found a use for this yet but it would allow the script to dynamically reprogram itself depending on the results of each block object's execution. You'd have to be careful not to get stuck in infinite loops though.
The block objects might in turn load various helper objects to define the content for this block. For example, a ForumsList block object would use Board, BoardsList and Forum to build a list of forums. Block objects relate to page layout areas - the kind of thing you'd stick in a div with an id.
As well as $block_meta, a request handler also defines some presentation meta data - general stuff such as the Presenter to use, as well as an array of block-specific data:
$this->presentation_blocks['MyClass']['template'] = 'template_name.htm';
$this->presentation_blocks['MyClass']['print_order'] = 1;
$this->presentation_blocks['MyClass']['css_id'] = $this->css_id; // the block's div id
This is set as a PresentationRequest property. Later, each block object will add page vars data structures to the appropriate key:
$this->presentation_blocks['MyClass']['page_vars'] =& $page_vars;
Now PresentationRequest has all the info needed to output each page layout block. This is passed to a Presenter. Presentationrequest is just a data store - it's the Presenters which actually print the page.
So, request handlers provide a single location to define the page structure and presentation using the $block_meta and $presentation_blocks arrays.
Usually that's all they do - but if any request processing is required (ie anything in addition to building a page to send to the browser) it's managed by the handler.
Form submission processing for example would be carried out by a request handler. The POST array would be checked and either the data would be processed prior to defining meta data for a "success" page, or (if required data is missing) the meta data used to build the form page would be set. The http request would also be redefined in the latter case to provide all the $request_args required by the form object - including a $message "please enter a title" or whatever, and any previously entered field values.
Note that the same block object page vars can be output in different templates & css id's on different page types - the page's request handler is free to choose. It would also be easy to create a bunch of xml handlers and an xml presenter - and so on.
After several revisions in recent weeks, I think I'm getting close to the final design but it is still experimental and I wouldn't want to put this forward as "the" way to do it.
Will be away for a week from tomorrow but will try to get online if I can.