Jump to content

A different way of using templates / delegate approach


Soma

Recommended Posts

hi isag, welcome to the forum!

your templates include what you tell them they should include... an easy example:

template1.php includes style1.css

<!DOCTYPE html>
<html>
<head>
    <link rel="stylesheet" type="text/css" media="screen" href="<?= $config->urls->templates ?>css/style1.css" />
</head>
<body>
    <?= $page->body ?>
</body>
</html>

template2.php includes style2.css

<!DOCTYPE html>
<html>
<head>
    <link rel="stylesheet" type="text/css" media="screen" href="<?= $config->urls->templates ?>css/style2.css" />
</head>
<body>
    <?= $page->body ?>
</body>
</html>

-----------------------

or you can use a _main.php file and populate just the variable blocks/styles/values in your template:

_main.php

<!DOCTYPE html>
<html>
<head>
    <link rel="stylesheet" type="text/css" media="screen" href="<?= $stylesheet ?>" />
</head>
<body>
    <?= $content ?>
</body>
</html>

tempate1.php

$stylesheet = $config->urls->templates . "css/style1.css";
$content = $page->body;

include("_main.php");

template2.php

$stylesheet = $config->urls->templates . "css/style2.css";
$content = $page->body;

include("_main.php");

hope that helps :)

remark: no correct code - just to clarify the principle!

  • Like 2
Link to comment
Share on other sites

  • 2 weeks later...

sorry for the late repply. i believe the last solution is the best for me. Its just that i was used to have a separate directory for each theme, like in drupal, and all its files (.css, .jpg, etc) would be inside it. I tooke me some time to see the advantages of this.

thanks!

Link to comment
Share on other sites

  • 4 months later...

You didn't even scratch on the surface yet... :) It's possible, just if it makes sense or there's isn't any drawbacks is a different question.

If you want you can overwrite and change almost everything. And if not, there's maybe just a hook needed to add to core. There's many different approaches as always in PW.

Fo example you could set all templates to have "main" as alternative template 

foreach($this->templates as $tpl){
     if($tpl->name != "admin") $tpl->altFilename = "main";
}

Depends really where you put this code. Most sense would make inside a autoload module like the HelloWorld.module. But then you have ALL templates always use main.php. You can't change it unless you add more logic to this script.

After all I've come away from the "delegate" approach I've posted here, and use the one Ryan proposed. Including the main.php at the end of a template file makes things easier when you want to add stuff per template. Some more flexibility after all. 

Hi Soma, I've recently been experimenting with your original delegate approach and I like the idea of having a single main template file that controls everything else. But like thistimj mentioned, it doesn't give you a place to set variables or put in template-specific logic before the view is loaded. What do you think of the idea of having a separate templates/controllers/ folder where you store a controller file for each template (just like your views folder), and then including that automatically in main.php before you output the html and the view file? This way the programming logic is still kept separate from the view.

So, in other words... Every template is set to use main.php.

Then, main.php:

  1. Sets up any variables/arrays and loads in css files, scripts, php functions the that apply the site as a whole (site-wide controller)

     

  2. Loads the template-specific controller which adds to or modifies these variables/arrays to suit the particular template. The template controller would also include things like form processing.

     

  3. Outputs the basic html structure (header & footer) and with the css/scripts

     

  4. Includes the template-specific view (within the html structure)

Some of the above parts could be further broken off into separate files, depending on the needs and complexity of the particular site. But now I am starting to question whether the 1-1 relationship of template controller to view really makes sense. So maybe the view(s) should be set as variables in the template controller, more like Ryan's method.

In the end I suppose the two methods can end up very similar. The delegate approach just eliminates the need to include the same files from each template file (or setup the prepend and append for each in the admin).

Link to comment
Share on other sites

  • 1 month later...

I was struggling to find an easy solution to templating and finally it seems I'm found the one that suits for me. 

The annoyances I have with the default PHP templating is string concatenation, too many php tags, quotes, etc. I was experimenting with output buffering and heredoc and though they worked, it felt a bit hackish. Installing a templating module would be another solution but I would have liked to avoid that if possible.

I'm using Nette framework nowadays and its Latte templating system is very nice. Fortunately it can be used as a standalone component so I gave it a try, and I could make it work with minimum efforts.

In short, it works this way:

  • "_init.php" is autoloaded by PW so I initialize the Latte engine there. I'm adding a new "$t" object here to which later I can add properties that will be passed to the template file.
  • PW loads default page template "basic-page.php" for example, so I use this file as a controller. It does nothing special, only adds extra variables the actual template needs. For example "$t->myPages = $pages->find(...)".
  • "init.php" sets the current template file, which is named similarly to the $page->template, and loaded from the "views" subfolder:
$latte->render('./views/' . $page->template . '.latte', $parameters);
  • $parameters is an array of variables passed to the view file. It has $page and $t too
  • I had to make a fake class to set the default "@layout.latte" layout file, so I don't need to set it in each view file (perhaps Latte will have this feature by default in the future)

So far it works beautifully but of course the proof of the pudding is the eating. I feel I'm having the best of the two worlds :)

Link to comment
Share on other sites

That's a good question, it bugged me all afternoon but I couldn't manage to get to my computer to check :)

Apparently I added "require_once($page->template . '.php')" before rendering the template with Latte.

The problem is that this way the template runs twice which is by far no optimal :(

I guess I should I use an empty custom template file instead but I'm curious if this could be made without that.

Link to comment
Share on other sites

@tpr

Maybe you want to check out my module: https://github.com/wanze/TemplateEngineFactory

It works similair to your workflow, e.g. using the ProcessWire templates as controller. Advantages: It does all the setup for you and provides you an API variable to interact with the template engine. Latte is not supported at the moment, but it would be pretty easy to implement. Drop me a line if you'd need help with the implementation.

*Advertisment mode off*

Cheers

  • Like 1
Link to comment
Share on other sites

Ok, a better solution:

1. _init.php: set new "$t" object to hold template variables

2. _main.php (set in config.php to automatically append): initialize Latte:

require_once("../latte/latte.php");
require_once(__DIR__ . "/../latte/FakePresenter.php");

// (optional) auto-load default @layout.latte
$presenter = new FakePresenter;

$parameters = array(
    '_control' => $presenter,
    'homepage' => $pages->get('/'),
    'page' => $page,
    'basePath' => rtrim($config->urls->root, '/'),
    't' => $t
);

$latte = new Latte\Engine;

$latte->setTempDirectory('../cache-latte');

$latte->render('./views/' . $page->template . '.latte', $parameters);
Link to comment
Share on other sites

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
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...