Replace PHP Templates

[drolsen]

@elseloop Lets use this ticket to keep an on going conversation about PHP template shift.

I know we are working on a Handlebars version to replace our PHP templates, but I thought it might be worth while to show how Jade template engine would work (branch: http://tinyurl.com/zlvqzjg).
Jade is widely used and actually comes with Node Express for application framework.

• New html driver; jade API configuration directly from gulp file! (http://tinyurl.com/ztkq5zy)
• Global and local vars with an options.jade to condition them if needed.
• Layouts separated / extend to templates (http://tinyurl.com/hehbddx & http://tinyurl.com/zjh3c88).
• Produces html files. did I mention that yet?
• Includes are welcome
• MIXINS!

I built us a helpful form field mixin too: http://tinyurl.com/huaz8dl

• input (all types, but none are inline) = http://tinyurl.com/z6egpjj
• inline radio = http://tinyurl.com/j4hgd4c
• inline checkbox = http://tinyurl.com/j2uenbz
• select = http://tinyurl.com/zco9lan
• textarea = http://tinyurl.com/goqdwfn

Ultimately this leaves us working with cleaner template source: http://tinyurl.com/hwon6vg
Also, much maths can be done: http://tinyurl.com/ja3p2py

Code references = http://jade-lang.com/reference/
Jade gulp file configuration = http://jade-lang.com/api/
Gulp Module = https://www.npmjs.com/package/gulp-jade

And discuss...

[ajmueller]

I've been using Jade on a lot of projects lately and LOVE it. Plus it's being renamed to Pug and who doesn't love pugs?!

I think the only concern might be how back-end devs would be able to digest the compiled HTML templates. Having PHP templates broken out into easily digestible pieces that line up well with Sitecore or other CMS components makes it easy for them to copy/paste into their environment. Using Jade, they'd have to have a way to know how they need to be broken up (which may very well be handled perfectly by using HTML comments similar to how @kamsar uses HTML comments to separate Sitecore components).

[drolsen]

@AJMuller Good point. I did add a /inc/components/ folder for us to house our include components (I think something we are trying to do more often now), however I too wonder if these would be easily digestible for backed implementations.

[ajmueller]

@devinrayolsen ah, very nice. Since the compiled HTML results in those components being incorporated into other HTML, though, the best way (I would imagine) to help back-end devs would be to add './templates/inc/**/*.jade' to the paths property of the HTML rendering config option. That way you get the components compiled into the larger templates, but they also get compiled on their own. This, along with comments in the Jade templates to help with context, would allow back-end devs to consume the markup without having to learn Jade's syntax (plus they can copy/paste as before).

[drolsen]

@AJMuller Great point, thanks! Updated.