Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Add support for... #43

Closed
jonschlinkert opened this Issue · 17 comments

6 participants

@jonschlinkert

IMPLEMENTED IN ASSEMBLE v0.6.0! Any engine can be registered like:

assemble.engine('swig', require('engine-swig');

Templating engines under consideration. Comments/feedback encouraged.

If you would like an engine added to the list, please make a comment on this issue so I can add it to the list for consideration.

@doowb doowb was assigned
@doowb
Owner

@kylehotchkiss we had originally started looking at consolidate, but I was having issues for adding things like partials and helpers in handlebars. Also, I'm thinking I had some problems with getting it to pre-compile templates, then rendering by passing in the data later. My main goal is to define a spec for what an engine should allow and build out engines that are just wrappers around other engines (consolidate could be used when we do that). Some engines don't offer pre-compile, so I understand the reasons behind how consolidate works.

If you have any suggestions or want to send a pull request, please feel free. We'd like all the help we can get.

@jonschlinkert

@doowb what about using consolidate for some engines? e.g. engines not "officially supported"?

@jonschlinkert

Meaning that we could temporarily shim the task with consolidate to help us build the spec.

@doowb
Owner

@jonschlinkert and I talked about handling template engines and we have come up with a spec that should work. We're going to support assemble engine plugins that should expose the following methods:

compile(content, options, callback);
render(tmpl, options, callback);

These methods will be similar to how consolidate sets up their render method, but we're splitting it out into 2 methods so we can call them explicitly. Anyone writing an assemble engine plugin is welcome to leave out compile and just provide render, which will make it easier to support consolidate.

Optionally, assemble will be calling two (2) methods during the processing steps to allow assemble engine plugins a way to setup helper functions/filters and register partials (these terms a coming from Handlebars and swig)

In a grunt file:

assemble: {
  options: {
    engine: 'handlebars',
    registerFunctions: function(engine) {
      engine.registerHelper('awesome', function() { return 'This is my awesome handlebars helper'; });
      return engine;
    },
    registerPartial: function(engine, filename, content) {
      var tmpl = engine.compile(content);
      engine.registerPartial(filename, tmpl);
      return engine;
    }
  },
  myTarget: {
    files: { 'path/to/dest/', ['path/to/src/**.*.hbs'] }
}

We'll be providing a couple of assemble engine plugins that show the usage of these methods and how we'll default them, so they aren't required.

@jonschlinkert please add anything you think is necessary, or let me know if I missed something.

@jonschlinkert

Assemble's goal is to make it easier to work with templates and data. This is just intended to give us more experience providing support for multiple engines, so we might end up with a better long-term solution. feedback is always welcome.

@nathanprobst

+1. Any guidance on when this approach will be implemented? Templates are a very personal thing, so accommodating a wide variety of preferences (mine is Jade) will help this project gain traction and acceptance.

@jonschlinkert

@doowb correct me if I'm wrong, but technically any engine can be implemented any time, by any developer. It's a matter of writing adding an engine to Assemble (we really should call them "connectors" or middleware, because you're not really creating an engine, just hooking it up).

@jonschlinkert

actually, I created a proof-of-concept jade helper recently that allows you to compile jade templates inline, with handlebars or markdown. I can't think of a real reason to use it, I created it as an example because it demonstrates the flexibility of what can be done with assemble and helpers.

if I get a chance later I'll push it up and link to it.

@doowb
Owner

@nathanprobst We've made some progress on removing any handlebars specific code from the assemble core. As of a couple of weeks ago, rendering is done with one pass (before it used handlebars style with adding a body partial, then rendering), so any engine should be supported.... it just needs to be wrapped if it doesn't support compile and render

(@jonschlinkert just replied while I was typing :grin: )

Check out assemble-handlebars on how we wrap compile and render.... Also, we started making a wrapper for swig to show another way of doing it.

I know the last couple weeks have been busy (at work and in my personal life) and @jonschlinkert is about to have a baby, but I'm hoping to make time to knockout a lot of these assemble issues over the long weekend. Of course, any help is welcome :wink:

@jonschlinkert

I'm closing this, adding engines is a part of assemble, it doesn't need to be an open issue any more

@waynedpj waynedpj referenced this issue in assemble/assemble.io
Closed

Why are there two template libraries? #74

@welldan97

Hi guys @jonschlinkert, @nathanprobst. I've just made engine for jade, which works fine so far with partials and helpers. I hope you'll find it useful. Cheers.

@jonschlinkert

@welldan97 thanks! much appreciated!

@airtonix

by the way, you should be using liquid.coffee instead of liquid.js.... actually you should just be creating an abstract TemplateEngineBaseClass that lets us describe how templates (and the template tags and filters) get rendered.

@jonschlinkert

assemble v0.6.0 makes this extremely simple.

@airtonix

@jonschlinkert in what way? configuration settings or by using render plugins?

If it's configuration settings, then you've just delayed half the problem for a short while.

But if assemble render process is done through plugins then good stuff.

Also links to any documentation or blueprints describing this new v6 render process please.

nevermind, I just found the #v0.6.0 branch. very nice work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.