General developer forum

Thanks for trying this out - I am sure others will learn from your attempts - and you might be able to find early limitations in our integration with mustache which we can fix before release.

Great that you think that my work on the »cleanm« Mustache based theme may be helpful.

I had used the »dynamic partial« helper to be able to make Mustache templates more flexible. Your proposal to »render_from_template« the partial in the wrapper renderable into the »$data->pagecontent« variable should do the same. I'll try that approach and come back with the result.

With the approach to use as few helpers as possible I agree. 

But if I would need a helper for a certain task Mustache is very flexible by making it easy to just add the helper when I need it. The Moodle implementation locks the Mustache instance away and reduces the flexibility Mustache offers. That approach I see as not helpful. I would prefer to be able to access all Mustache features from within Moodle.

Great proposal Damyon to use the render_from_template('partial/partialname') call in the renderable instead of a »dynamic partial« helper. With very few changes in the code the helper is not needed any more.

I updated the moodle branch to the latest weekly and committed the theme changes. And I reverted the »dynamic partial« helper commit - it's not needed. You may get the changes form the GitHub repository - or have a look at https://github.com/uhunkler/moodle/commits/master.

Do you know why the course context and the doctype

$contextcourse= context_course::instance(SITEID);
$doctype = $OUTPUT->doctype();

need to be called in the layout.php? I first had the two lines implemented in the »base_layout« renderable but Moodle complained - for example about the missing doctype call.

After some further thinking about the »dynamic partial helper« I come to the conclusion that I prefer to use a »dynamic partial helper« over the rendering step Damyon had proposed and I had implemented in the latest version of the »cleanm« theme.

The main reason is not technique but concept - I think separation of code generation and layout with templates is a big advantage. When I call a renderer with a template in the code generation process for another renderer with a template I start to mix code generation and layout again.

So I prefer to be able to think about the process as three steps with as much separation as possible

1. Get and calculate all data
2. Create a template with the page look
3. Fill the data into placeholders in the template to render the output

With these steps I can concentrate and work on the best solutions for back-end and front-end solutions more separated. To be able to mentally separate step 1 and step 2 helps me a lot to finetune and optimize the result.

The conclusion

So please let's implement a »dynamic partial helper« - it will be useful the same way in PHP and JavaScript.

Thanks for your great work on this Urs!   

that cool eh?

Some years ago I would have agreed with you, Howard, when I dropped Smarty from Moodle.

But look at the problems that the current renderers have caused in many themes because designers (who are usually not expert programmers) have to implement PHP that slowly gains in complexity and unreadability until it becomes code that breaks on core upgrades.

The idea of proper templates is to separate design-related things from logic-related things and I think most designers will be really happy with us taking this approach using mustache.

A very important aspect in working with web development/design are the mental models people are using.

I am an educated Graphic Designer and a developer. When I work with Moodle I always »see« the resulting pages in the browser. And I »see« the DOM tree in the browser's developer tools. My mental model is the styled page with the underlying DOM tree.

The best results I can achieve when I am able to use code that comes close to my mental model - that means something looking similar to the DOM tree which is something similar to HTML.

Code coming close to a HTML page is a template. Preferable a logic less template language (like Mustache). So with Mustache templates I am able to create better results with less effort - because the code I work with looks close to the mental model I have from the final page.

PHP as a template engine would help if it would be used in the pure form: Write HTML and echo out the data - without any logic in the page. By the way Mustache templates technically come close to that approach, they »only« abstract out the echo statements and the conditional/loop statements in visually compact code and make the page better readable as a HTML page.

Mustache:

<ul class="listing">
   {{#data}}
    <li class="list-item">{{oneitem}}</li>
   {{/data}}
</ul>

HTML/PHP mix:

<ul class="listing">
   <?php foreach ($data as $oneitem) { ?>
   <li class="list-item"><?php echo $oneitem ?></li>
   <?php } ?>
</ul>

Or with a renderer:

<ul class="listing">
   <?php echo $OUTPUT->listitems($data); ?>
</ul>

The less »foreign« code is used in the page the clearer the HTML page structure gets. In the example with the renderer I don't even get any information how the list items will look. I need to check the renderer code. The page drifts away from my mental model of the page in the browser the user sees with each step of abstraction. A Mustache template is the closest I can get - it works with the least amount of non HTML code.

I guess the principle to separate code generation from code output is somehow agreed about - it is the same prerequisite for renderers and for templates.

• For code generation Moodle uses PHP
• To display the page in the browser Moodle uses HTML
  
• To get the code into the page with least cluttering HTML Moodle uses Mustache

Another valuable aspect of Mustache templates is that you can create representations of page areas in a template. 

• With PHP you can use this template on the server to render the HTML page delivered to the browser. 
  
• With Javascript you can use the exactly same template to render the page area in the browser when the data has been delivered for example from an AJAX call.

Howard, I think PHP and Mustache are not that »cool« at all as you call it.

To work with Jade templates, the Stylus CSS preprocessor and JavaScript written in CoffeeScript is cool. With this combination of languages/transpilers even the development language specific elements like brackets, semicolons etc. are stripped out. The structure produces the meaning. It is possible to work with the »pure« information.

The content plays the main role and not the language specific representation. I would like to exaggerate a bit in the context of this discussion and say code is drilled down to it's essence.

I like the puristic and structured form of development. This might also be an explanation why I prefer Mustache templates over PHP/HTML mixes or PHP renderers.

I think that mustache has the potential to make things a little less complex.  I say potential because I've setup a ghost blog to teach myself mustache, and from 0.5.6 to 0.6.0 they've added increasingly more and complex helpers with each release.  The potential for things to go wrong is if we add a million logical helpers into mustache that exponentially multiply the amount of output variables by the number of renderer tweaks and overrides.

So, as long as mustache is actually logic-less I don't care, but If I have to start controlling logic from a renderer (override) and then manipulating the output with mustache then it becomes a problem.