workflow with "HTML Imports": frontend design first, ProcessWire next...

[szabesz]

Warning: it's going to be TL;DR so proceed with caution

In an effort to come up with an optimized development workflow, I have come up with the idea of implementing most of the required template files in the form of static HTML files first (based on a "CSS framework" which will also serve as the CSS base of the site).

Basically I want to implement most of the frontend without touching ProcessWire in the first place. The advantage of this approach is that it is a lot faster to work with only HTML/CSS/JS during the frontend design phase of the project, and the end result of the design phase can be "similar" to a wireframe/mockup which can be presented to a client, but this "mockup" actually represents (say) 80% of the final design, so it is something that is rather good to work with when the backend development with ProcessWire begins.

This also means that my ProcessWire template files will be mostly implemented with <?php echo ... ?> and alternative syntax control structures that can be "just injected" into the above mentioned static HTML template files to turn them into ProcessWire template files later on.

So far so good, but my ProcessWire template files are going to be separated into "template file partials", and I also want to implement the static HTML template files in the same way, so that they are also separated into "template file partials", and ideally organized in the very same structure.

E.g. I will include the site's navigation in the ProcessWire template file like this:
<?php echo $navigation ?>
So I want to do the same in the corresponding static HTML template file, something like this:
<div data-template="partials_navigation"></div>

If it can be done recursively, then I can implement the same in both cases. With ProcessWire, I use wireRenderFile() to render partials recursively, so I just had to figure out what to use in the case of the static HTML template files.

What else to use if not JavaScript? I started off by googling around, looking for some pre-made solutions... I did not find too much that could help me, the only thing useful I could dig up is "HTML Imports", for example:
http://blog.teamtreehouse.com/introduction-html-imports

Note, that currently this technique only works in Chrome(-ium), but that is my choice in frontend development anyway. I've read somewhere that other browsers might never implement "HTML Imports", but that is to be seen...

I have found a lot of articles explaining the basics of "HTML Imports", but I could not find any libraries or frameworks nor even something similar to what I need, so I implemented a proof of concept version of mine:

  Reveal hidden contents

/* Loads template partials form files.
 *
 * Recommended browser: Google Chrome
 * Only works if Chrome is launched with --allow-file-access-from-files
 * Alternatively use Brackets' live preview feature.
 *
 */
var linkedTemplates_o = document.querySelectorAll('link[rel="import"]'); // collects all the <link rel="import"> elements

for (var i = 0; i < linkedTemplates_o.length; ++i) { // loops through the <link rel="import"> elements

    var linkedTemplate_o = linkedTemplates_o[i]; // a template file partial to work with
    var template_o = linkedTemplate_o.import.querySelector('template'); // importing the template file partial

    /* we turn (e.g.) partials/article-lead-button.html into partials_article-lead-button
     * this way we can identify all the "data-template" div elements 
     * which will be replaced with their associated template file partials
     */
    var templatePath_str = linkedTemplate_o.attributes['href'].value; // geting the path to the template file partial
    var dataAttributeValue_a = templatePath_str.split("/"); // splits it up like PHP's explode
    var dataAttributeValue_str = dataAttributeValue_a.join("_"); // joins them again like PHP's implode
    dataAttributeValue_str = dataAttributeValue_str.split(".").slice(0, -1).join("."); // removes the extension

    var selector_str = "[data-template='" + dataAttributeValue_str + "']"; // we will look for this data-template attribute value(s)
    var templateNodes_o = document.querySelectorAll(selector_str); // collects all the data-template divs in question

    for (var j = 0; j < templateNodes_o.length; ++j) { // loops through the data-template divs we found
        var templateNode_o = templateNodes_o[j]; // a data-template div to replace with its associated template file partial
        var templateContent_o = document.importNode(template_o.content, true); // represents the HTML code of the template file partial
        templateNode_o.parentElement.replaceChild(templateContent_o, templateNode_o); // time to replace
    }
}

 

I'm quite happy with the result so far. The JavaScript code needs some additional error handling, but otherwise it seems to do what I need.

Here it is in action (Chrome(-ium) only!!!): [...no longer live...]

And here is the source code for those who want to take a closer look: [...old stuff, I removed it to save space...]

However, I'm pretty sure that someone must have already come up with this idea, so I'm asking the ProcessWire community if anyone can point me to similar solutions, something that I can study and/or use.

So any piece of advice that might help me to take it to the next level, or any objections to this "HTML Imports" technique, any disadvantages? Thank you in advance

[LostKobrakai]

You should probably take a look at this one: https://medium.com/webdevs/living-styleguide-mit-fractal-und-processwire-e900f05e0b79#.vij9p35p8
(I know I should translate it some time, but I heard it's quite readable with google translate)

[pwired]

Since the introduction of the delayed output strategy by Ryan this has been discussed in many posts and I have used it ever since and I have fine tuned it until perfection.

https://processwire.com/talk/topic/8767-regarding-delayed-output/

https://processwire.com/talk/topic/11199-mainphp-inflexibility/

using wireRenderFile() in the delayed output strategy
https://processwire.com/blog/posts/processwire-2.5.2/

https://processwire.com/talk/topic/11836-wirerenderfile-on-child-pages/

Here Camilo Castro explains how his wire render pattern works:

https://medium.com/@clsource/the-wire-render-pattern-806bf6d6097a#.jquhbxejn
https://github.com/NinjasCL/wire-render-pattern

Horst came up with the idea to use $Layout for using different layouts for any given page on the front

https://processwire.com/talk/topic/8767-regarding-delayed-output/

https://processwire.com/talk/topic/11769-delayed-output-and-another-layout/

with this I call html files in a folder "views" for front pages who need a different layout

Then I used your own former mentioned strategies here:

https://processwire.com/talk/topic/2311-processwire-on-the-web/page-21#entry109766
https://processwire.com/talk/topic/11809-pw-site-profiles-are-like-wp-themes/#entry109848

https://processwire.com/talk/topic/2311-processwire-on-the-web/page-21#entry109851

 

Together I am using this here as an example set up in my _main.php file: (the variables shown here are not always the same but depending on what a web site needs)

<?php include("./banner/{$banner}.php"); ?>
<?php include("./topnav/{$topnav}.php"); ?>
<?php include("./subnav/{$subnav}.php"); ?>
<?php include("./slider/{$slider}.php"); ?>
<?php echo $layout; ?>
<?php include("./footer/{$footer}.php"); ?>

Any value for css, js, values, etc for a specific page on the front can be over rided, switched on or off as desired on each associated template file. Further I use separate css files for the main part of a web site and individual css files for front pages where needed and call for them between <head> and </head> with $variables on the associated template files. Output happens with the $Layout as mentioned before. Values used site wide are set in the _init.php file and can be changed or switched on or off as needed on the associated template files. This makes it all highly organized and fast maintainable.

Reading through your proposed workflow looks like I am already are applying that. Would be interesting to find out how and where your proposed workflow would improve on my current workflow.

 

 

[tpr]

I always wonder why u guys don't use a template engine instead. Most things you try to achieve are already there and on a more sophisticated/bulletproof level, and there are many more goodies. Ok, it takes some time to get familiar with them but the productivity boost they give is worth the effort imo.

[pwired]

  Quote

I always wonder why u guys don't use a template engine instead.

Expand  

That is something that pops up every now and then and certainly is something to think about. However Processwire's API does already just the same, but offers more flexibility and possibilities.

https://processwire.com/talk/topic/1403-template-engine/?do=findComment&comment=12626

 

[szabesz]

@LostKobrakai and @pwired Thanks for directions. I'm going to have a busy day this Monday, but will definetally take a closer look of the posts you provided. Note, that I've already adopted @clsource's (Camilo Castro's) wire render pattern thanks to his recently released Processwire Ghost Writer profile which I am currently refactoring to my needs.

@tpr Well, there are various reasons for not taking the template engine path, at least not yet. You have almost converted me and I was about to jump the Latte bandwagon, but  currently I want to work with the least amount of dependencies and a template engine is just another framework to add to he system which is not really needed for standard, basic websites which I'm currently interested in.

[LostKobrakai]

I think ditching template engines for what you're trying to do is probably not a good idea. You want to fill in html templates with various data. Static in the first place and dynamic in a second step. That's exactly what templating engines are made for and you'll probably not come far without at least implementing something like a small templating engine on your own. But a own implementation does also need own maintenance and documentation and so on and it's probably not as powerful as existing solutions. They may be a  additional dependency, but really a own library is a dependency, too, which is just harder to maintain.

[horst]

Some years ago, (maybe 10 ?), I worked with a nice and useful tool: Tiny But Strong. It is a OneFileTemplatingEngine in PHP, with 1 PHP-class, 6 methods and 5 properties. If I recall right, I was able to do every thing with it. Besides Tiny But Strong, it also was Simple And Easy To Use.

It is under constant development / maintenance since 2004!