Template Engine

[Pete]

I think for certain profiles like the blog profile there could be a template switcher, but its use would be limited because as soon as you change the template files themselves too much it would begin to fall apart.

I think for certain profiles it does make some sense though as a way to get started quickly with a different design.

There is also the opportunity if you're bundling the templates folder to have a different layout entirely for a certain profile too, which is nice and flexible.

I think what needs to happen first is for there to be more than just one template for the blog profile for example and then we're talking.

[Joss]

Yes, I can't see how you would employ the traditional idea of themes.

Profiles are not an alternative because they are not applied retrospectively.

The nearest I could see is if a developer created a range of profiles that used exactly the same styling system, and then created alternative themes - but that would not work outside of that environment and you would only have to play with the profile a tiny bit for this to stop working.

None of this I see as a problem, because I don't see ProcessWire as being aimed at that part of the market place.

Although the growth of profiles will be important, it really is in a subtly different way than people choosing WP because they found a nice theme:

• They show what is possible,
• They give starting points for less techy developers (like me!)
• They are short cut starters for more techy developers (who are naturally lazy)
• They provide framework variations

Interestingly, I think there is more value in developing "module" plugins to give quick functionality - styling from scratch can be very quick; creating functionality can be laborious sometimes.

For instance, a simple blog module would come with fields, page hierarchy (including category and tag selectors), templates and template files (as much split out into "inc" files as possible), all laid out in a very neutral way.

I would be "almost" usable out of the box, but would really require styling and fitting into the existing site structure.

These would be labour saving rather than instant solutions though - probably created by a developer to help themselves.

But then, that is how PW started years ago!

[MatthewSchenker]

Greetings,

I agree with Joss...

One of the central reasons that ProcessWire is so great is specifically becuse it does not have a "templating system." This might be uncomfortable for people who expect plug-and-play templating frameworks like you get in Joomla or WordPress, but in fact with ProcessWire you have the whole design world as your "template system." Yes, it assumes that the HTML/CSS/JS is not done for you.

Of course, it is possible that the ProcessWire community could develop a library of layouts and styles that could be used in projects, but -- and I think this proves the main point about ProcessWire templating -- those layouts and styles would be applicable beyond ProcessWire!

Joss -- interesting idea for project-based modules... Perhaps we could one day group modules into "sets": blog sets, news sets, community sets, etc? These sets could help people build certain kinds of ProcessWire sites faster, and you could pick and choose among them for your project.

But back to templating: I came here from the Joomla world, where templates are a constant hindrance to open designs. I hope ProcessWire never goes down that road!

Thanks,

Matthew

[Natetronn]

Nate, I don't see how front-end themes could come from just adding template engine.

I don't recall saying front-end themes could come from just adding a template engine. In fact, my last post (see next quote) for the most part tried to move away from the original title of this topic to what is was meant to be about from the start which was finding ways to make things easier on users. The template engine was an idea though, yes, off topic from Ryan's original post as I remember it; I see that now.

Bringing up template engines was only one idea to help make things easier for people though, I'm sure there are many other ideas as well.

PW is much more flexible in it's data modelling than WP and markup generation (just like EE is) and that is the reason there cannot be traditional "themes" that can be just switched.

I agree with this and mentioned something to that extent in my last post as well.

With that said, I guess I don't know what the original topic from Ryan was about anymore to be honest because PW isn't really setup to be easier than WP rather, by design, to allow freedom to model data among other things like you said. I'm going to have to re-read that topic again I guess.

@Joss I think Drupal does something similar with their profiles in regards to having a set of profiles which are module based though, also theme based. That of course isn't like WP and is a one time install just like PW would be as I remember it.

It is however a good idea to allow people to quickly setup common sections of a site like a blog to help keep things DRY. So, site profiles which aren't necessarily theme based that could be installed at any point one needed them would be nice. Client needs a blog now, you just grab the "blog module/s based profile" and go.

I seem to remember seeing a module which would help for quickly setting things like this up though, I don't remember for sure. EE has something similiar which may never see the light of day but, you can still check it out here.

[apeisa]

I don't recall saying front-end themes could come from just adding a template engine. In fact, my last post (see next quote) for the most part tried to move away from the original title of this topic to what is was meant to be about from the start which was finding ways to make things easier on users.

Sorry, I misread your last post. 

It is however a good idea to allow people to quickly setup common sections of a site like a blog to help keep things DRY. So, site profiles which aren't necessarily theme based that could be installed at any point one needed them would be nice. Client needs a blog now, you just grab the "blog module/s based profile" and go.

I have been thinking about that a lot lately. I think that to get PW more popular "one click features" like blog, news, products etc are great idea. There are few things that slow down that road currently:

• Export and import of templates & fields - that will be huge time saver when creating such a modules (if you take a look my shopping cart checkout module, there is quite a lot code just for field/template/page creation)
• Field duplication: should each feature bring their own fields, like blog_body or re-use existing ones? If the latter, then we might need to increase the amount of "default" fields. Maybe as simple as adding few more fields to starting profile.

[JeffS]

A solution might be to create a profile with some common elements, blog. sliders, galleries, portfolio, etc.. using something like twitter Bootstrap or Zurb Foundation for example. Then have a couple of different stylesheets to "customize the look".   You get the same effect as a "theme".  People could easily install the profile, customize the site stylesheet , add content, and be up and running. 

 PW is not WP and that is a great thing.

[niutech]

I've just integrated Smarty in ProcessWire, which seems to be faster than Twig. Details in another thread.

[artaylor]

Hi,

Brand spanking new to ProcessWire and I must say I am very impressed so far.

My background is 24 years in non-web development, and recently working with Joomla, WP, Drupal, custom PHP and learning Laravel.

I would like to suggest that this is not "syntax" question as it is just as easy to learn <?php echo $somevar ?> as it is to learn {{ somevar }}. However, as a developer who is working on a team with a designer, I really believe it is important to separate out display from logic. It is too easy to give a designer with limited PHP experience the requirement to use PHP to create their template (WP anyone?). We all know what happens with a missing ; in a PHP script... BLANK SCREEN. This is totally unacceptable in a team/enterprise environment and also, I think it is a flawed design decision.

I understand that PHP was initially disigned as a template language, but it has moved beyond that at this point and PHP5 is a decent programming language. So, we are really saying that we expect designers/users to actually know and understand a full programming language when all they want to do is create an HTML template that has some placeholders to put their content.

Laravel was mentioned in an earlier post. I think it is a brilliant product and it includes Blade, a templating language. Why? Because it is important to allow non-PHP developers access to this awesome technology while still allowing the developer full access to the framework.

I work on small teams with a designer and a moderately competent user. As it stands, I would not let my user or my designer have too much control over the PHP so that means more work for me so I don't get the 3am phone calls saying the site is down because they missed a ; or a closing >.

This is a project with HUGE potential and I think KUDO's are deserved to everyone involved, especially Ryan for having a brilliant vision and forsight. Let's not make this a "geek" only tool but be inclusive to others by allowing an alternative to PHP as the templating language. Think beyond a one man shop and this product has tremendous potential.

My 2 cents!

Anthony

[Pete]

This isn't meant to disagree with what you've just said, more just understand the processes people follow when working in teams.

Why would you let your designer work on templates in your final system at all? The way I do it when working on my own sites is to build templates separately and then copy and paste the HTML into the ProcessWire templates, which to me seems sensible over letting a designer do tweaks on the actual system. Where I've worked in a team this was also the preferred way of doing things - the dev would be the one to actually insert the final HTML into the template files.

This is definitely more about me not knowing other people's processes than anything else though so please do weigh in with your experiences.

The other thing to bear in mind is that even with a templating engine they could still type PHP into the template files so it wont stop them, but on the bright side if you don't tell them they can then they're less likely to do it

And welcome to ProcessWire Anthony.

[Pete]

Also worth noting is that porl has created a Twig module here: http://processwire.com/talk/topic/1421-twig/?fromsearch=1 and there is a Smarty module somewhere on the forums recently too so you could try both of those out.

I can't see either being the default though because the system is designed to make few/no assumptions about the end user, but there are a few options there at least

[Wanze]

I agree with Pete.

In my opinion, the "Designer" or "Front-end-guy" should do his stuff in plain HTML/CSS/Js. Then the dev copy paste this into a Pw-Template and makes it work there.

A Pw template does not only output static html, most of the time you combine this with your fields assigned or you need to display data from any Pages anywhere on your site. This again is a task for the developper, maybe you must create new fields or queries before. Then you can mix this with the code from the designer.

Using a Template language, you have the same problem: If the designer messes up the tags, ther Parser will throw an error and your template isn't displayed.

That said, I don't know this workflow because where I worked, I received a .psd and had to do the front- and backend coding myself.

[Joss]

In my huge team of one, I work like Pete - I design away from the final environment, even if that means pencil and paper. 

The results of that I put into the system.

But in reality, just like my proper job of a composer/sound engineer/producer, the system has become very blurred with creative people doing technical jobs and technicians doing creative jobs.

When I first started in the seventies, this was only just happening really - there were still the sound engineers who got fussy about non-engineers touching the faders (especially in the BBC which was stuffed with idiotic union members who were not even good sound engineers).

But the technology changed this with the result that a lot of professional music is composed at home by untrained engineers - and it is good stuff too!

The whole point about languages like PHP is that as natural languages they are meant to be easy to use by non technical users. They are intentionally designed to blur the boundaries to make the design process more coherent.

Now, obviously keeping some separation makes debugging much easier and allows for redesign without changing the mechanics, but I don;t think that means there should be no trespassing at all on each others territory.

Personally, I don't see a problem with that as long as the end product goes through some QC and fulfils the brief.

Also, on a purely selfish note, I am only just beginning to get my head around PW as it is - without learning yet another syntax! (Old brain does not absorb stuff as easily as it used to)

Joss

[diogo]

Agree with all above, but even with the workflow you referred, I don't think PHP is more dangerous than a template engine sintax because in that case, all the PHP will have to be very simple as you will have to implement a trully MVC system, right? If so, because all the complex logic will be out of the "view" files, you will always have very simple and not dangerous PHP code for the designers to work with:

<?= $page->title ?>

or at the most:

<div>

<? foreach($page->children as $child): ?>

<h3><?=$child->title?></h3>

<p><?=$child->body?></p>

<? endforeach; ?>

</div>

[Joss]

Very neat, Diogo

Or you just wrap the entire lot in a function that has very minimal markup that can be bent with CSS and then shove it into your template:

<div class="myBigContainer">

<?php loadPageRubbish(); ?>

</div>

[teppo]

Hello there, @artaylor, and welcome to the forum!

Just like Pete above, I've got absolutely no problem with template engines - as long as they stay out of my way

What I do have to disagree with is the general idea that template languages makes things simple and programming languages difficult. Template languages generally start with a good idea ("separate code / logic from markup / view") but eventually end up re-creating much of native functionality and only making things more complicated for everyone. Designers still need to learn new (template) language and developers not previously acquainted with that particular template engine have to do the same just to keep up and provide often necessary support.

Just take Twig as an example; it's really quite amazing how complicated structures any moderately resourceful designer can create with relatively simple tools like macros, conditional logic, variables - especially when combined with template inheritance and horizontal reuse.

I also strongly disagree with your notion that designers would need to know and understand "a full programming language" simply to create HTML template with some variables. Exactly why would they need to do that, if all they need is echo and some simple control structures? How would this part be so different when using a template language instead of PHP?

Based on what you've said there some template languages seem to be pretty fault tolerant, but I can't help wondering if that's really a good thing - I mean, why shouldn't there be an error if something is clearly broken? What if it causes misleading information to be spread out, UI to be broken or any number of other problems?

One thing I do see value in is sandboxing, though. Like you pointed out, sometimes it's necessary to set limits for the amount of damage an inexperienced designer (or developer) can unintentionally cause. This is a good argument for template languages, though I'd still argue that most of these issues can be avoided altogether.

Pete and others have already provided valid solutions above. Another important thing is to never make changes on live environment. That's just plain wrong and will definitely cause problems eventually, no matter how skilled folks you've got. You can also provide designers with a simple checklist of things to a) do, b) not do and c) be careful about. IMHO that's much better than making everyone learn yet another language.

All that said, there's clearly a lot of interest in template engines around here nowadays, so you can be sure that eventually you won't have to teach another row of PHP to a designer. I still honestly wish that more designers could get over their phobia of these evil programming languages and realize that they're not that bad after all. This is one of the reasons why I won't ever advocate disguising or wrapping PHP (or any other "programming language") with something that's ultimately just another layer of complexity

Edit: even though this post is already horribly long, I just had to add that the way I see it such things as "pure" programmers, front-end guys or designers rarely exist in the world of modern web development - and that's a good thing. Learning what others do and how they do it, even if it's just the basics, can benefit everyone. No one benefits from tightly set roles, such as "designer can't write PHP, period."

Edited February 16, 2013 by teppo

[ryan]

ProcessWire is actually the first iteration of this CMS that doesn't rely on a template engine. And Dictator CMS (the grandaddy of ProcessWire) was entirely template engine based, with no PHP API or PHP support at all.

I'm no stranger to template engines. While there are benefits to template engines, my own experience has been that the benefits are largely perceived rather than experienced. There are also some tangible benefits too. But how many of those tangible benefits apply varies greatly from system to system. ProcessWire has a nice API, but most CMSs do not. For many of those CMSs, the template engine is what makes the system accessible (or at least, more accessible). Expression Engine is an example. In those systems, template engines are providing a huge benefit by isolating the developer from having to use a complex or crappy API. Nobody would use these systems without the template engine. But in a system like ProcessWire, a template engine is redundant, less capable, and ultimately more complex layer of overhead. 

Most of the time, we do not want that kind of extra overhead in ProcessWire. In our context, the only real benefits of a template engine are if you have some kind of syntax preferences (PHP is not always the prettiest syntax) or if you want to have a jail. There are some valid reasons to have a jail, as pointed out earlier… but I prefer education to jail. Still, I understand the reasoning and can't say it's always wrong. Just that it's wrong for a core default. There's also that benefit of perception. If one perceives there are some other benefits to a template engine, they will seek out systems that have them, even if perception isn't always reality. 

I believe strongly in the benefits of our current approach and API. I feel these benefits are far greater than what comes from any template engine. And I've discussed them at length many times in many places, so I won't rehash that all here. But I've always wanted ProcessWire to support template engines, just not to require one. So I like what I see with the Twig and Smarty modules. Actually, the Smarty module seems like it would be especially simple to work with, since it bolts in so quickly and easily. I hope to see more in this area and am always willing to do whatever it takes to support add-on template engines (we even added a hook or two to support the Twig module).

While I personally don't need these template engines and sometimes question their value, I also very much support them in ProcessWire as modules. Perception is powerful, and we're trying to grow our audience. Likewise, there may be some that have template engine preferences beyond just perception. Anything that opens a door for more people is a good thing. While ProcessWire's core isn't and won't be built around a template engine dependency, we fully support use and implementation of them as modules. And I'm also willing to add any new core hooks or capabilities necessary to support the development of such modules.  

[artaylor]

Wow. I did not expect this much response. I think it says a lot for the community and the passion behind Pw.

As I mentioned, I am very new to Pw so it is possible that once I get to know it better I will agree that a template language is completely unnecessary. Also, I have no problems with it being a module that can be loaded if needed. I certainly don't think it needs to be in the core. So, if there are modules that already exist then I am satisfied. For example, I hate TinyMCE is totally screws up my code. So, I don't use it, but it is there for those that want to. That is one of the things that I see with Pw that I like.

Thanks for all the feedback and comments!

Now, for my own enlightenment, I am interested in where you all draw the line between Design and Development. In my current situation, my designer knows HTML and CSS (he obviously knows design too). So, in my thinking, that is the demarkation point. I should not need a copy of Photoshop to develop and he should not need to load debugging tools, etc to design. He provides clean HTML/CSS and I fill the templates with data. That is why I feel it is important that the designer can modify the templates and not just hand them off to me to implement.

The user is expected to handle the data so why are we keeping the designer away? Is this not a 3-way partnership? I know that some of you are one-man shops and totally capable of doing it all, but I am trying to understand this from a small team perspective. I have done the last few sites in MODX Revolution and the designer was fine with being able to modify the templates and leave all PHP to me. If he needed something specific, he could ask and the same for me. The user just entered the content. It seemed to work well and balance out the work.

My musings... I will probably look back on this message and laugh at my Pw naivety. It's all good and thanks again for being so responsive and open.

Anthony

[Joss]

I cant speak from the web development world, but having been in the advertising, film and music worlds for 35 years I can speak for the web's great ancestors.

I think there is a huge difference between specialisation and isolation. 

In the industry I come from, although we do have dedicated technical roles, most roles are specialisations out of choice from people that start from pretty much the same point - a runner, mostly!

So, the the recoding engineer, voice over director, video editor, film writer, producer, advertising creative director, could have all been the same person originally.

That sort of evolutionary career path produces something that is vital in some of the huge, multi-million dollar projects I have been involved with over the years (often just in tiny way)

We all understand what each other does. 

That does not mean we could do each other's jobs, but we can bring our particular specialisation as a perspective. So as a sound person, I might pick up a visual edit that has not worked. An editor might notice a glitch on the sound track that I have missed.

This is all despite the fact that the unions over the years have tried to stop people knowing (let alone doing) each others work. 

So, basically I believe that there should be a team - between the client, the developer and the designer (and possibly the often neglected marketing/pr guru). And although each should bring their specialisation to the table, they should appreciate each other's perspectives and career-informed opinions.

To communicate those it helps if they understand each others work. And if that means the designer phoning the developer and saying "how can I grab that bit of data so I can play with it," then all the better. 

Sometimes treading on each other's toes is the beginning of being able to dance together...

Joss (2013)

[Wanze]

This was maybe already mentioned somewhere before, I haven't read all the posts.

In my opinion, a Template Enginge makes sense in a MVC environment where the view is clearly separated from the logic in the controller and does not accept PHP.

Usually it works like this:

<?php
//In Controller
$showNav = true;
$pages = query("SELECT * FROM....*");
$view->assign('pages', $pages);
$view->assign('showNav', true);

//In View
{if $showNav}
  //....
  {foreach $pages as $page}
    //...
  {/foreach}
{/if}
?>

In ProcessWire, you have the freedom: a Template can be just the controller and fetch another template for the output – or it can directly output Markup. Or you can mix those things up and leave the sometimes-overrated MVC-stuff.

I think for most projects it's fine to find a way between.

Personally, I wouldn't use Smarty in ProcessWire because when the Pw-Template is actually a Smarty-Template, where to put the PHP stuff? Where can I use the awesome Pw-API to search my content? Of course you can write smarty functions and assign variables in smarty, but this makes it again complicated. That said, I used smarty a lot and think it's great, especially the template inheriting stuff! But not in ProcessWire

[diogo]

@Wanze, the logic-view separation makes all the sense in the scenario that Antony referred, but to me it's perfectly possible to keep PHP very discrete inside the HTML with the PW sintax.

@Anthony, your team's workflow seems perfectly logical and healthy to me, but it still implies some understanding of what each other do. You show understanding for the designer's work when you worry about letting him have his code as clean as possible of PHP, and he has to show some understanding of your work by trying to understand how some basic but important programming things work. He has to know how a loop works and where his HTML should go inside it, or how a condition works, etc... and if he gets that on a template engine, he will also get it with PW as long has you are careful to keep all your complex code on another file.

[ryan]

Now, for my own enlightenment, I am interested in where you all draw the line between Design and Development. In my current situation, my designer knows HTML and CSS (he obviously knows design too). So, in my thinking, that is the demarkation point. I should not need a copy of Photoshop to develop and he should not need to load debugging tools, etc to design. He provides clean HTML/CSS and I fill the templates with data. That is why I feel it is important that the designer can modify the templates and not just hand them off to me to implement.

Creation of markup and CSS isn't technically a design task in the traditional sense, unless the designer literally designs in markup and CSS (a trend I like). Perhaps that comes from the places I've worked, but front-end development was always a development task. The designers dealt with concepts and visuals, not code (markup, css, Javascript and template engines are all code). I think there is more of a blurred line now though, that's a good thing… I've always liked having my hands in both. But I work with a few design firms that outsource development to me, and all provide me with layouts (whether photoshop or some kind of flat image type). I've never had a designer provide me with code... though maybe my experience is isolated there. Photoshop is both a design and development tool. I don't know many web developers that can do their job without some kind of image manipulation tool like Photoshop. So I would disagree with "I should not need a copy of Photoshop to develop". But I know different companies do it different ways. If you've got designers doing front-end development, that's great, but they are working with code, doing development. If they are producing good quality markup and CSS, and really know how to design, they are a "web designer/developer". That term is what defines most of our audience here. Your company should give those designer/developers a raise.  

So lets say that's your workflow. I agree with Diogo that this sounds healthy… so long as the designers know their front-end code as well as a dedicated web developer.

The "logic" that people use in ProcessWire templates is largely presentational logic. If you are trying to follow an MVC pattern, presentation logic is still a component of the view layer. I think this distinction is important. ProcessWire is already handling the business logic. It doesn't really matter whether you are dealing with a PHP API or a template engine, as the tasks are going to be the same.

ProcessWire templates can also be used for business logic. Typically we don't want to be processing forms, saving pages, etc., in the places we are generating markup for output, even if you technically can. There are a lot of good approaches one can take to separate concerns. If using an MVC approach, then you would isolate your presentation logic and markup to a separate view, like we do with the Blog profile. (Though in the Blog profile we really do this more for demonstration purposes, as there's not much in the way of business logic.) If you take this approach, you are using your ProcessWire templates as controllers and dedicating other files as views. You can use the TemplateFile() class for views, as the Blog profile does, or you can use some other template engine like Twig, Smarty, etc. I think that this approach may provide the right balance of separation for the environment you've described. But I'm not sure it's worth the overhead unless building some real business logic (like an application) rather than a traditional web site. 

Personally, I wouldn't use Smarty in ProcessWire because when the Pw-Template is actually a Smarty-Template, where to put the PHP stuff? Where can I use the awesome Pw-API to search my content? Of course you can write smarty functions and assign variables in smarty, but this makes it again complicated.

I'm not sure about the Smarty module, but the Twig module seemed to have the entire PW API available to it. 

[Joss]

Just thinking about what Ryan says about the real (or perhaps old) place for the line should be so that the devs also take care of html and css as well as serverside leaving the designer to come up with the concept.

Working like that does open the doors for great design to be sourced from outside of the web design world, bringing in some of the older or more specialised but brilliant designers that have not got involved because they know nothing about html (and have no time/interest in learning)

Years ago I applied for a job doing sound for a games company. My CV includes sound credits on several feature films, work on massive launches for X-Files movie and British Airways, sound-effects design for TV, film, radio drama (which is probably more applicable) and more, and voice director on thousands of productions.

Plus, I am a credited music editor and composer.

BUT, I don't know any C++ or C# and so on.

Sorry, said the idiot at the company, noting my lack of programming skills, we don't see what relevance your experience has to games. 

Their loss (and their subsequent game sounded awful), but it did demonstrate how easy it is to lose out on valuable knowledge, skills and creativity if you put the importance of technology above the needs of the product.

So, perhaps Ryan's observation has huge relevance even today.

Personally I still believe the pencil and paper is still the most powerful concept design tool there is.

[artaylor]

@joss: don'f forget the vital design tool called a restaurant napkin.

@ryan: thanks for your input. I have to say your experience would far eclipse mine in the web development world so I will take a solid look at how things are being done and perhaps move that line...

In general, I am working my way through my first PW project. It is more challenging than I thought it would be, but I think that is because I am making it more difficult that it needs to be and I need to "grok" this more fully. I keep thinking how I would do it in MODX then having to re-think it. It is coming along, albeit slowly.

Thanks for all the feedback. Excellent forum!

[Pete]

Let us know if you run into any issues or need to ask how to do something the "PW way" - usually you'll get a quick response and that certainly helped me transition from MODx to PW a few years ago

[Joss]

@joss: don'f forget the vital design tool called a restaurant napkin.

Ah, the modern, healthier version of the back of the fag packet ... er , cigarette packet (What do you mean, we aren't all Britons in here?)

In general, I am working my way through my first PW project. It is more challenging than I thought it would be, but I think that is because I am making it more difficult that it needs to be and I need to "grok" this more fully.

Now this I completely relate too. I keep adding bits because I wonder "how do I do this?" or "I wonder it this will work?"

Great fun, but I am worried about my productivity!