Other templating engines

[benedfit]

@dmolsen - With regards to handling other templating engines; had you envisaged ports supporting engines that were specific to their technology stack/platform, or would each port need to support all engines to comply with the spec?

[bmuenzenmeyer]

Relevant Issue: https://github.com/pattern-lab/the-spec/issues/5

[dmolsen]

@benedfit -

Let's break down Mustache support for two separate things: generating from core templates (e.g. index.mustache) and generating patterns. Mustache must always be used to generate core templates. Support for other template engines must be limited to generating patterns.

As for generating patterns, Mustache with a specific "pattern loader" (e.g. support for pattern partial syntax, style modifiers, and pattern parameters) must be supported to be in compliance with Pattern Lab spec. This will allow us to share assets/patterns/docs/starter kits amongst each port. Mustache must also be the default engine when a port is installed.

I'm leaving the door open for other engines for generating patterns if you want to support them on a per port basis as it makes sense for your underlying tech or task. They should be able to support, at a minimum, the pattern partial syntax. A decent example of this is Twig support in the dev branch of the PHP port. I don't expect node or .NET to have support for Twig but it's available for the Drupal folks who have expressed interest. The default and most feature-rich engine is and will continue to be Mustache.

[benedfit]

@dmolsen - Thanks for the answer, this is how I had interpreted it, and how I was planning to introduce the more widely used (in .NET anyway) Razor templating syntax into the .NET version

[dmolsen]

@benedfit & @bmuenzenmeyer -

The recent changes to the PHP edition to support front-end and back-end "extensions/plugins" has seen me drop Mustache as a core template engine. Basically, whatever someone chooses to load as a "pattern engine" for their install of Pattern Lab should now be able to parse the "view all" views and patterns.

I haven't updated spec but feel free to drop Mustache as a requirement. You can use whatever engine makes sense for your platform and use it for everything. There is also no need to match certain features like "pattern parameters" if it doesn't make sense for your pattern engine choice. For example, it probably won't make sense for the Twig pattern engine for the PHP edition.

This is how things are falling out for an organization:

• the "viewer" (the stuff under core/styleguide + the main index.html file) is now decoupled from the Pattern Lab PHP project. The main index file is now rendered in the browser. The PHP edition exports nav and config info as JSON which is then included and parsed in index.html. Mustache-based templates are baked into it and parsed by Hogan.js. This should allow for more flexibility between front-end and back-end. See the styleguidekit-assets-default repo.
• The "viewall/styleguide" mark-up (the stuff under core/templates) is now also decoupled from the Pattern Lab PHP project and stored in a pattern engine specific repo. See the styleguidekit-mustache-default repo.
• The demo material (the stuff under core/source) has also been decoupled from the Pattern Lab PHP project. It's now set-up as a pattern engine specific repo. See the starterkit-mustache-demo repo.
• Not that you'll find a pattern engine terribly interesting but you can check out the Mustache and Twig editions (not fully tested) at patternengine-php-mustache and patternengine-php-twig respectively.

I'm now using composer to manage dependencies. If you decide you want to add your own package management config to a repo like styleguidekit-assets-default let me know.

More changes are on the way. The feature-plugins branch is where I'm committing right now. I'm feeling comfortable with the back-end structure tho core/ will end up thinned out and shoved into its own package too. Next up for me is to allow for front-end plugins to modify the "viewer". Then lots of documentation >.<

PS - I apologize, this turned into a status update. But, hey, now you guys know what's going on :)

/cc @bradfrost

[dmolsen]

And for further updates see issue 51 on the PHP repo.

[bmuenzenmeyer]

@dmolsen Definitely interested in using this - will think through it and let you know if I have questions. :)

[dmolsen]

Related to this… the dev branch of the Pattern Lab Thin Edition shows the file structure I'm going with for Pattern Lab in the future. patternlab-php will match it though have more default dependencies in composer.json. Pattern Lab dependencies will get installed in packages/ or vendor/ which are both created as needed.

If you curious to get a better explanation of the various components that will make up a Pattern Lab project in the future I tried to write a little something up about them.