Jump to content

WIP: TemplateFileHelper & AjaxIntercoolerJS


Recommended Posts

I pushed an initial (testing) version of TemplateFileHelper to bitbucket.


The autoload module extends TemplateFile instances with 

API vars $layout and $view

  • $layout -> global layout instance of TemplateFile to set layout placeholders ($layout->set(...) or global scripts / styles.
  • $view -> current page instance of TemplateFile to set the current page placeholders and current page scripts / styles.


load() method

Load a template / view with additional controller (php) file as subTemplate. Returns a TemplateFile object to render / output
Each sub-template controller have access to API Vars and $subTemplate (current TemplateFile instance, $subTemplate->set('placeholder', 'My value...')).

Load site/templates/chunks/test1.php controller and site/templates/chunks/test1.tpl view:

$part = $view->load('chunks/test1');
echo $part->render();

chunks/test1 example

// chunks/test1.php - controller
$subTemplate->set('var1', "Subtemplate variable output...");
<!-- chunks/test1.tpl - view -->


scripts / styles properties

FilenameArray like $config->styles | scripts. It should help to organize scripts / styles with ajax in mind (global / current page only).

// current page script

// global / layout script

You have to handle the output yourself by two foreach loops inside your _layout.php / _layout.tpl files (non ajax calls scripts and styles should be in layout head section).

foreach ($layout->scripts as $globalScript) { ... }
foreach ($view->scripts as $currentPageScript) { ... }

IntercoolerJS module will take care about async / ajax handling of (custom page) scripts and styles.


hook Page::render

hook after page render to load and add the global layout. The current page template (PW template file == controller) just handle the currents page code / view. Global layout / controller / view is moved to separate files (default: _layout.php controller and _layout.tpl view). 

Just use $layout->set(...) to fill the _layout.tpl placeholder variables inside the _layout.php controller file.


configurable module

Some settings are available...

  • Global layout (view + controller) file name (default: "_layout")
  • Current page content variable (used inside of the _layout.tpl view to output current page content, default: "currentPageContent")
  • View file extension (default: ".tpl")
  • Controller file extension (default: ".php")



It will be a dependency of the planned IntercoolerJS module which adds ajax page calls, async scripts / styles handling (current page scripts and styles...) and need a defined template handling to work...

Edited by pwFoo
Title modified
  • Like 6
Link to comment
Share on other sites

After some changes (removed "echo $view->render()" output from PW template file) it works like TemplateEngineFactory module from @Wanze.
I think about abandon my TemplateFileHelper draft and switch to the existing (and maintained?) module. 

But I have to think about the script / style handling to be compatible to the planned IntercoolerJS module (global and custom page scripts / styles). TemplateFileHelper module would handle styles / scripts by TemplateFile instance ($layout ==> global, $view ==> current page ). So IntercooolerJS module is able to remove / replace "current page" scripts and styles to prevent side effects between ajax loaded pages.


So I have to decide if TemplateFile calls like setFilename() and render() should be written to the PW template file (with my module draft) or handled by the module (hook Page::render, maybe switch to TemplateÉngineFactory).

If pw template output is replaced by the rendered view maybe debugging could be difficult because output won't visible!

It feels like more "control" if debugging output is visible and the controller includes the "echo $view->render()" call :rolleyes:

Edited by pwFoo
Link to comment
Share on other sites

And it could be difficult to attach styles and scripts loaded by PW modules (like "JqueryCore") to global or current page scripts / styles...

$config->scripts / $config->styles isn't hookable (FienameArray helper class) and I don't know how to detect the automatic loaded styles and scripts.


Any suggestions how to detect automatic loaded styles and scripts?


I think I have a simple solution... Move $config->scripts to the right context...

// Define as current page
$config->scripts = $view->scripts;

// Change to global before take care about the global layout
$config->scripts = $layout->scripts;

All Scripts / styles manually and automatically (PW modules like Inputfields, JqueryCore, ...) loaded are assigned to the needed context.

Link to comment
Share on other sites

Added IntercoolerJS response header methods... Maybe I reduce the number of methods (for example combine setPollingInterval, cancelPolling, resumePolling with a param to switch case).

     * Set x-ic-trigger response header
     * @param array $array One or more events with related data arrays
    public function trigger($array) {
        $json = json_encode($array);
        header('x-ic-trigger: ' . $json);

     * Set x-ic-script response header
     * @param string $js Valid javaScript code
    public function script($js) {
        header('X-IC-Script: ' . $js);

     * Stop current / parent element Intercooler polling
    public function cancelPolling() {
        header ('x-ic-cancelPolling: true');

     * Resume current / parent element Intercooler polling
    public function resumePolling() {
        header ('x-ic-resumePolling: true');

     * Set current / parent element Intercooler polling interval
     * @param string $interval
    public function setPollingInterval($interval) {
        header ('x-ic-setPollInterval: ' . $interval);

     * Set x-ic-refresh response header
     * @param string $pathCsv Comma separated paths to refresh.
    public function refresh($pathCsv) {
        header('x-ic-refresh: ' . $pathCsv);

     * Set x-ic-open response header
     * @param string $url New window / tab address
    public function open($url) {
        header('x-ic-open: ' . $url);

     * Set x-ic-redirect response header
     * @param string $url Redirect destination address
    public function redirect($url) {
        header('x-ic-redirect: ' .$url);

     * Add ajax redirect handler to Session::redirect
    public function hookSessionRedirect($event) {
        $event->replace = true;


Also successfully tested AjaxIntercoolerJS with Frontenduser :) 
I'll do some more tests with PW inputfields (via FormHelper) soon.

  • Like 1
Link to comment
Share on other sites

  • 1 month later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Create New...