#162 Smarty function xoMeta: non-cached header values

[rowd]

The objective of this patch is to allow dynamic insertion of content into the document head of cached pages.

A new method is added to the "xos_opal_Theme" class, which is registered in Smarty as non cacheable. This method can be used in Smarty templates and understands the following syntax:

<{xoMeta type="stylesheet" src="modules/page/style.css"}>

where the value of 'type' is either 'link', 'stylesheet', 'script' or 'meta'. Extra parameters are required depending on the type chosen. The stylesheet type used in the example requires either the 'src' parameter for a source file, or 'content' parameter for css code passed as a string.

See the relevant class methods in class/theme.php for more details.

The patch was built against 2.3.0-dev (trunk revision 807)

[rowd]

xoMeta Smarty function

[Jan Pedersen]

Logged In: YES
user_id=841117
Originator: NO

Awesome, this works like a charm and is VASTLY needed.

[Jan Pedersen]

Logged In: YES
user_id=841117
Originator: NO

A bit quick there - what I MEANT to say is that it works like a charm and will definitely be a valued addition for me.

However, two things to look at:

1) $parms -> $params (for clarity)
2) check indexes for existance ($params['content'], $params['attributes'], etc.) so we avoid
Notice: Undefined index: content in file /class/theme.php line xxx

[rowd]

Logged In: YES
user_id=1095348
Originator: YES

I agree with changing $parms to $params, the XOOPS Smarty plugins also use the $params syntax.

The notices I'll fix - left the error suppression operator off for testing, forgot to add it again.

I've also discovered that I need to change a few more files on the admin side. I'll post a new version this weekend.

Thanks for your interest :-)

[Jan Pedersen]

Logged In: YES
user_id=841117
Originator: NO

One "small" problem with this approach: It is not recognized when parsing the template on module installation/update thus causing a fatal error.

is it necessary to use $smarty->register_function() instead of as a normal plugin to get the nocache? If not, I would suggest adding it as a smarty plugin function - that will also avoid the calling of register_function() on each and every page load, regardless of whether it is used.

[Jan Pedersen]

Logged In: YES
user_id=841117
Originator: NO

A little further research leads me to the xoops_template_touch() function (/class/template.php) which instantiates a new XoopsTpl object directly.

This template ought to instantiate the xos_opal_ThemeFactory object instead and then call touch() on the theme object's template property.

Perhaps something like this:
function xoops_template_touch($tpl_id, $clear_old = true) {
$tplfile_handler =& xoops_gethandler('tplfile');
$tplfile =& $tplfile_handler->get($tpl_id);

if ( is_object($tplfile) ) {
    $file = $tplfile->getVar( 'tpl_file', 'n' );

            require_once XOOPS_ROOT_PATH . '/class/theme.php';
            require_once XOOPS_ROOT_PATH . '/class/theme_blocks.php';
            $xoopsThemeFactory =& new xos_opal_ThemeFactory();
            $xoTheme =& $xoopsThemeFactory->createInstance();
            $tpl =& $xoTheme->template;

    return $tpl->touch( "db:$file" );
}
return false;

}

Although it seems awfully inefficient to instantiate the $xoTheme object like this every time - however, for backwards compatibility (modules may call xoops_template_touch() somewhere) it may be necessary.

[rowd]

xoMeta version 3

[rowd]

Logged In: YES
user_id=1095348
Originator: YES

The 'few more files' I mentioned was to fix the template compilation problem, but imo it is more a Smarty issue than a XOOPS one. Anyway, the updated patch provides a workaround.

The issue imo is with the Smarty compilation procedure.
What happens:
1. enter the Smarty _compile_file() method
2. validate each template tag
A. is the tag registered? if not, load from plugin directory
B. does the function exist/is the method callable?
If validation 'A' is not met then the compilation ends and returns an error status. If validation 'B' is not met then compilation continues but a warning is generated.
3. check the cacheable state of the tag, extra code is generated for non-cacheable tags
4. add code to compiled template for runtime handling

So because compilation also validates, I need to register the runtime xoMeta tag function. But Smarty ignores the cache setting anyway when validating, so the tag function needs to actually be callable at compilation time.

For standard plugins (file located in the plugins folder and using Smarty naming syntax) the logic works, but for custom registered plugins I think this is incorrect logic. Standard Smarty 'function' plugins though cannot control caching at the level we need.

File Added: xoMeta-v3.zip