Make JTemplate object oriented and hook to JHTML

[garyamort]

Currently the template code is not very object oriented.   The current setup is as follows:

Every view has a $template variable set to the name of the template.   Views build dual paths, one to the template folder using the template name and one to their own path and load views via checking for a file in the template path, then their own path.  JHtml doesn't use templates at all and the code is pretty much hardcoded into their path.   JPagination is function based and limited - you either define a an alternate pagination function in your template, or you don't, and it applies to ALL calls to it with a single set of functions, there is no context[for example, I recently had a website where for one component we had a google map, and others did not.  This called for different pagination layout depending on if you viewed the map or not, so we could not use the pagination function as it can't be overwritten for a single component easily.

To my thinking, this really should be wrapped up into an overall template object.   As examples:

$view->loadTemplate should be devoid of most of it's logic and should instead call:

$this->template->loadTemplate  - where the logic can be pushed down into a JTemplate object.   JTemplate can default to the current JView logic, but can also be overwritten and allow for things such as inheritance[so a template can define "parents" and use those parent templates to check for template overrides as well.

In JPagination all calls which are returning html should instead be calling the template directly, for example:

$chromePath = JPATH_THEMES . '/' . $app->getTemplate() . '/html/pagination.php';

if (file_exists($chromePath))

{

include_once $chromePath;

if (function_exists('pagination_list_footer'))

{

return pagination_list_footer($list);

}

}

This is FIXED, you can only have one function called pagination_list_footer.  Instead, this can be redesigned as:

return $app-getTemplate()->pagination_list_footer($list, $context)

Where getTemplate returns a JTemplate object, and the default pagination_list_footer method does the same thing getListFooter currently does for html theming.  $context can include such information as the component the footer is being generated for, the current active component, etc.

Lastly, take the powerful JHtml class.

$text = JHtml::_('image', 'system/emailButton.png', JText::_('JGLOBAL_EMAIL'), NULL, true);

JHtml will load the JHtmlImage class and pass it the parameters.   JHtmlImage then formats the data passed to it and generates the html.

To my thinking, it would be better for JHtmlImage to do all the data formating, and then to call $app-getTemplate()->html('image', 'system/emailButton.png', JText::_('JGLOBAL_EMAIL'), NULL, true);

JTemplate can then redirect this right back to a display/render function in JHtmlImage as a temporary measure so it retains the current functionality.  Template authors however could extend these functions to generate alternate html for the specific template.

I'll try to get an example set of code out this week.  It sounds a lot more complicated then it really is, as a lot of this can be done in manners which are backwardly compatible,  [For example, define a magic toString method in JTemplate so that it returns the template name..this way any code dependent on the old structure will continue to work]