-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Process templating syntax in content files as well #35
Comments
Actually, talked about something similar with @treygriffith a while back about this plugin technically should have been made as two plugins. One for the idea of "layouts", probably |
Yeah I think it would! I think that would be great. @mayo, this would work for you as well right? |
@ianstormtaylor, if you're game for this as a solution, is there anything I can do to help? I'm not on your level as a coder, but maybe there's something I can do? |
@ismay I haven't touched this code in a while, but I think to split this into two plugins would just require copying everything over into both new repos, and changing lines 73-79 to only support one option from the conditional for each plugin. Just dividing this plugin into two separate plugins with a clear purpose / use case would be a huge step in the right direction, and probably focus some of the conversations - it should become pretty clear which of the two new plugins should be responsible for which proposed features. |
Personally, I would dislike it if it was split into two plugins. I think it would cause more confusion. A lot of the issues spawn from using consolidate, which imo is a pretty hacky way of attempting to integrate all the possible templating engines. Sometimes it's impossible to realistically have the same API for all of them; some precompile templates, have template inheritance, or the possibility of adding filters or global functions. With that said, there has to be a better way of supporting a simple templating engine plus the ability to 'tap into' the underlying engine instance (by means of e.g. a |
@garygreen, I guess there's a tradeoff. On the one hand having a single plugin that processes templates makes sense, to avoid duplication of otherwise pretty similar code. But on the other hand it also makes sense to me to separate it into two because we're talking about two different tasks:
I could go either way. A simple option for metalsmith-templates that toggles
I'd say that this isn't about passing options to the templating engine, but more about metalsmith-template's processing logic. Tapping into the underlying templating engine would be nice, but is a different issue as I see it. But I agree, that would be nice. @ianstormtaylor , @treygriffith : given what garygreen's said, what's your preference: still want to separate the functionality or keep it in a single plugin? Just so I know what to works towards. |
@ismay yes sorry, I was going a bit off topic! Probably another issue (more to do with consolidate.js) which is why I have to initialize my own nunjucks-template plugin. Hmm actually on second thoughts I can see why this plugin should be split up into two...that's IF it's to remove the template inheritance support with the Therefore I would like to see:
In the instance of using just swig/nunjucks, you would use number 1 and define the template you want to use in your actual source file (or just none at all), instead of in the yaml matter: src/home.html---
title: Homepage
---
{% extends 'layouts.main' %}
{% block content %}
blah
{% endblock %} layouts/main.html<html>
<title>{{ title }}</title>
{% block content %}{% endblock %}
</html> Essentially your using your source files as full views, with the ability to add yaml matter that automatically get's sent to your renderer as include data. That would be awesome and clear up a lot of confusion I think. |
@garygreen, If you want to do that you can just set
As right now, |
Ok, so these two repos are working examples of what we've been talking about:
I did some testing with both plugins, and combining them works just fine (tested with What does everyone think? Proceed with this? Because then we'd need a concensus on the names (layouts and templates for example) and one new repo, to allow me to create a pull-request for both plugins. Also, if this is what we'll do then the new
|
Those look cool to me! Would you be interested in maintaining them yourself (ie. not transferring back)? Totally fine with me if you want to go that route as well. |
You mean just maintaining them as alternatives next to the canonical metalsmith-templates? |
Because then maybe it would be good to rename To me the main goal is an option for in-place templating that's independent of the application of (layout) templates to the files in |
Out of curiousity, is there a reason it wouldn't work to just invoke the template plugin twice, once with |
@lygaret, Ha, yeah that's a lot easier :). Only possible improvement on this would be putting this in a single plugin with two independent flags in my opinion. What do you think @ianstormtaylor, shall I remove my versions of |
Oh sorry, I totally would have suggested that solution, I use that too. I On Sun, Nov 16, 2014 at 6:02 AM, Ismay notifications@github.com wrote:
|
@ianstormtaylor, Ok, I've made some final changes and they're both ready for use. Quick recap: https://github.com/ismay/metalsmith-templates @ 1.0.0
https://github.com/ismay/metalsmith-layouts @ 1.0.0
I might have made a mistake or two, but as far as I can tell everything works just fine (worked fine when I tested them). Only thing that I haven't updated yet are the tests. As far as I'm concerned this issue is resolved, but please feel free to reopen if I've forgotten anything! |
For posterity:
|
I've seen a couple of issues and pull requests that all relate to processing the templating language in content files, in one way or another: #21, #24, #22, #27, #26.
I'm opening this issue to focus discussion on what I think is actually at the core of these issues and prs, to hopefully reach a solution more quickly and eliminate any confusion. Let me briefly summarize (and reiterate what I said in #21):
inPlace
), but still want to apply the template as defined in the front-matter (whichinPlace
does not do)Extending
As I said in #21 (and as others have said as well), extending templates is more a functionality of the templating language, and does not have to be added to metalsmith-templates (in my opinion). It's already possible.
Process contents
So that leaves the second bulletpoint: processing the templating language in content files, whilst still applying the template as defined in the files front-matter. I think solving that would basically directly or indirectly address all issues and prs mentioned above.
So what would be the best solution to address that? A new option, or modify
inPlace
(if this corresponds to what it was originally meant to do)? @ianstormtaylor , what do you think?The text was updated successfully, but these errors were encountered: