Styles Templates: Allow object method calls
 

Before you chew me out for suggesting that we allow PHP in templates* please hear me out (because that's not what I'm suggesting).

The new vB Template syntax is a good step in the right direction. It creates more verbose code that is easier to read. But we're still lacking something that would be solved by allowing PHP in templates. However* as so many people seem to be dead-set against that* how about a compromise?

What about allowing the Template to call a method of an object that's passed to it? Something like the following:

PHP Code:
class Formatter {
function renderHeader () { /* standard header code* probably an include */}
function renderBanner () { /* standard banner code */ }
function renderFooter() { /* standard footer code* probably an include */}
function render () {}

class MyObjFormatter extends Formatter {
..
function render () {
.. some code
}
function renderFooter () { /* override std footer code */ }
}

$myobj = new FormatterObject($param1*$param2);

$templater - vB_Template::create('GENERIC_SHELL');
$templater->register('mycustomobj'*$myobj);
print_output($templater->render());

And then you could do the following to the template...

PHP Code:

{vb:call_raw $myobj->renderHeader () }

{vb:call_raw $myobj_renderNavbar() }
{vb:exec $myobj->render() }
{vb:call_raw $footer->renderFooter() }



In this case* vB_Template would call the functions of the object that you pass to it. In my example above* I'm taking a very OO approach and I'm providing a base Formatter class that handles the rendering of the header* footer* content and pagetitle for me. (By doing this we could easily remove 99% of the container templates (FORUMDISPLAY* STANDARD_** etc) and just use GENERIC_SHELL for just about every page. This would reduce alot of the duplicated code in the templates and with some judicious splitting up of the current templates* it would allow us to re use some of the existing code that's already out there simply by making a call to it.)

But that's just a side benefit of this idea. What I'd like to be able to do is not have all of these monolithic scripts that marry the display code and the processing logic in the same file. I'd like to see the different display portions of the code split up into smaller portions and turned into objects and then have be responsible for their own rendering.

For example* I've often had to duplicate the code for "userinfo" from the postbit template. I'd rather just require_once (class_postbit_userinfo.php)* instantiate the object with a userid passed to the constructor and then call render. This would allow me to do all sorts of things like re-use templates AND code... without using copy-paste.

Similarly* if I need to add a new kind of post (for example* vbulletin.org's plugin format)* I could do so by extending the postbit rendering class* making my own changes and then just sending that kind of object to the template instead.

Now* I get that most vB admins aren't PHP or OO savvy* but the fact is that most of those will never do anything more than install plugins and ask questions in the community forums on how to edit templates. But the rest of us would truly benefit from having the ability to add dynamics behaviors to the templating system.

Note: Some are likely to ask how this differs from the existing code base where we can just call render on a template* fetch the results and then print_output.

Well* the magic is in the ability to separate custom code from the vB code base. Because each Formatter class could be responsible for it's own rendering* you'd almost never have to change the vB code and/or templates. And if you did* those changes would be minimal and would only pertain to those portion of the templates where you actually made changes.

It's not the custom code that is the biggest vulnerability to vB users* it's the fact that upgrading to a later version is such a PITA if you've done extensive template & code hacks. Because updates are so painful* many people skip releases and updates and so are left with known security holes issues.

Therefore* I'm for any idea that helps me reduce the number of mods that I have to make to the stock vB system (and I'm also for partitioning the templates to a more granular level) :).

Cheers*
Dave.