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

change markdown header format to be more flexible #155

Open
soapdog opened this issue May 18, 2015 · 6 comments
Open

change markdown header format to be more flexible #155

soapdog opened this issue May 18, 2015 · 6 comments

Comments

@soapdog
Copy link
Contributor

soapdog commented May 18, 2015

Hey Friends,

Been working here trying to convert my docpad site to harmonic and stumbled upon some issues one of which is that I am using the document/post/page header to convey more data to the template than what we can currently do in harmonic.

One example is a post where I want to list links that are related to the article at hand. On my current site source, I have an array of objects in the header in a field called links, each array element has a title and a url. This is assembled by the template in the sidebar.

This could be done in harmonic if we simply passed all the data from the header to post.metadata and switched the current header format. Right now, we're relying on marked-header node module which uses a DIY to parse the human friendly header format into an object. Unfortunately that module can only handle simple key/value pairs and trying to pass a more complex data is not possible.

My enhancement advise would be to change the implementation of marked-header module to use a friendly syntax in the header that is more powerful than the current one. I would advise using some YAML module because all the current headers would still work and we would have features to pass more complex stuff.

Without the ability to pass more complex data along with the document it becomes trickier to drive plugins and create more flexible templates.

@UltCombo
Copy link
Member

I believe YAML would take a bit longer to parse, but it seems like a good choice IMHO.
Feel free to experiment and send a PR. :)

@UltCombo
Copy link
Member

@soapdog By the way, since you've already contributed substantially to the project and we are adopting the "open open source" governance model (or something like, @jaydson and I are still ironing the details), we can provide you with commit access to the repo if you'd like.

@jaydson
Copy link
Contributor

jaydson commented May 18, 2015

Hey @soapdog, you are talking about marked-metadata module, right?
I think i didn't understand the problem you pointed.
I've built the marked-metadata module because i wanted exactly what you said, more flexibility in the posts data than marked module have.

About YAML, i think we can support it, but not just YAML.
There's no reason to throw away JSON format support.
(Just ignore what i said if it is not the proposal)

As @UltCombo said, you're very welcome to be part of the org @soapdog :)

@UltCombo
Copy link
Member

@jaydson does marked-metadata support arrays/objects as values of a key? That's what @soapdog is proposing as far as I can see.

@jaydson
Copy link
Contributor

jaydson commented May 18, 2015

Actually, i don't know ahahah

@jaydson
Copy link
Contributor

jaydson commented May 18, 2015

I think it supports JSON.

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

3 participants