Skip to content
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

Ability to provide files as part of the context #1

Open
amr opened this issue Dec 14, 2013 · 4 comments
Open

Ability to provide files as part of the context #1

amr opened this issue Dec 14, 2013 · 4 comments

Comments

@amr
Copy link

amr commented Dec 14, 2013

In my project I need to provide some icons as part of the context. I think it may be a good addition to groome.

@cjerdonek
Copy link
Owner

@amr, thanks for the suggestion! Do you have any thoughts on syntax? I have some preliminary thoughts of my own, but figured I'd ask.

@amr
Copy link
Author

amr commented Dec 14, 2013

Thanks for asking! I think one DRY/KISS approach would be to support a new top-level directory e.g. "files", that would be applied/copied recursively to the output (after it is generated).

@cjerdonek
Copy link
Owner

@amr, so I had a chance to think about this some. I'll walk you through my thought process, so let me know what you think.

The use case you described can almost be handled with the current system by having a template file containing a single tag like so:

{{{ project_name }}}.png.mustache
    {{{ logo_png }}}

However, this doesn't quite work because there is an assumption in Mustache that the files are text files. I'm thinking then that the use case above could be addressed by adding a new "template" extension/format that works something like the following:

{{{ project_name }}}.png.copy
    logo.png

The content of a file with extension .copy should be a single path, and the path should be the path to a file in a top-level files directory. If the renderer encounters a file with extension .copy, the renderer copies the contents of the corresponding file in the files directory to the location as is.

The files directory would be like a supplementary context -- some of whose values can be binary.

If I understand your approach correctly, I think an approach like what I described would be even more DRY because, for example, you wouldn't need to maintain a parallel directory hierarchy. You would also be able to place several copies of the binary file in your project template while needing only one copy in the files directory context.

@amr
Copy link
Author

amr commented Feb 4, 2014

That's a pretty neat solution! I think it also means that the template is self-describing. i.e. by looking at the template directory one would be able to tell what files/dirs will be in the resulting directory without having to go to the files directory and try to comprehend the result after applying the latter to the former.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants