Quote from: garryn at Jul 13, 2006, 04:33 PM
One question about the overview and the roadmap: Which part of the roadmap covers the resource element maps? I’ve been looking over bits of the new core to get a feel for it and want to make sure I can place all the different elements.
A modResourceElement map is simply how modElements are attached to modResources explicitly, in much the same way as Template Variables are attached to Templates today. So, what is being conveyed in the diagram is the loose coupling between Resources and Elements, where the Base Template is used to explicitly attach a Template element to a Resource, the processing of which may include parsing additional Elements represented by tags in the content, and/or resource element maps, which are the logical extension of Template Variables, allowing additional Elements to be directly related to/customized for a Resource. Most elements can also define dependent elements that can act in much the same way as Resource Element maps, so when assigned to a Resource as a Base Template (or Element of any type), the traditional Template Variable scenario is covered. Just to help connect the dots a little further, consider that a Context can then isolate specific Resources and/or Elements to certain sections of your site, and I think you’ll start to see how this will allow all sorts of new possibilities without sacrificing the existing MODx approaches.
And don’t forget that you can write your own Element class derivatives by simply implementing a single process() function, overriding the behavior or replacing it completely.
For instance, the modSnippet is a derivative of the modElement class which defines all the functionality needed to process a PHP code snippet via a MODx tag (e.g. [[ScriptElement]]); so to implement the current functionality of MODx plugins, I created the PluginElement class that consists of simply:
<?php
class modPlugin extends modSnippet {
function modPlugin(& $xpdo) {
$this->__construct($xpdo);
}
function __construct(& $xpdo) {
parent :: __construct($xpdo);
$this->set('class_key', 'modPlugin');
}
function process($properties= null, $content= null, $cultureId= null) {
$this->output= parent :: process($properties, $content, $cultureId);
echo $this->output;
return $this->result;
}
}
?>
That’s how easy it will be to create your own Element classes to do just about anything you can imagine, including just slightly altering the behavior of an existing Element implementation.
NOTE: The dual constructors you see are part of the code generated by XPDO, and is used only to help bridge the gaps in PHP 4 and PHP 5 object behavior, specifically to allow PHP 4 to always fall through to the PHP 5 style constructor, as well as allow PHP 4 to call the parent constructor without having to know the actual name of the parent class.
MODX Staff
MODX Staff
(And thanks Ryan for the "translation" of some harder concepts : certainly helped me) !
