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

Default template parser #20

Open
jxson opened this issue Sep 27, 2011 · 3 comments
Open

Default template parser #20

jxson opened this issue Sep 27, 2011 · 3 comments
Assignees
Milestone

Comments

@jxson
Copy link
Owner

jxson commented Sep 27, 2011

Currently haiku treats anything in site.content as if it were text and needs to be parsed by mustache.

To support the Rocket.ly use case of having everything in content directory (i.e. not needing to have a separate public directory) I think we can add a configuration option like:

defaultTemplateEngine: false

Which would turn off the behavior of assuming mustache is okay to run on any files in the content directory and only use a parser if it is called for in the file's name. So with defaultTemplateEngine set to false a directory like this:

. content
|-- favicon.ico
|-- index.html
`-- about.md.mustache

Would only have the about.md.mustache file run through Mustache and Markdown, the other would be left alone.

Also having a defaultTemplateEngine will allow one to set their default engine to Handlebars for instance once we add support for it and not require the .handlebars extension added to the end of every file

@ghost ghost assigned jxson Sep 27, 2011
@dyoder
Copy link

dyoder commented Sep 27, 2011

I like this. Nice way for everyone to get what they want without making things awkward.

By the same token, I think we might want to have some sort of template registry that is exposed and can be modified in the config. And then we can have a mapping of extension to engine. So that way, you can decide to just use, say, .hb for handlebars templates.

@jxson
Copy link
Owner Author

jxson commented Oct 4, 2011

I have a hacked version of this working in the default-template-parser branch but ran into a caveat. File encoding :(

We need to know the file encoding before reading the files into the page objects and before writing the files out in the build and deploy process. Otherwise things like the favicon.ico will not be read or written properly using this example.

@jxson
Copy link
Owner Author

jxson commented Jan 13, 2012

related: #42

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