using meta.json

[parmentelat]

Hi there

First off, many thanks for putting this together ! Looks like a really cool idea and I got my micro website up and running in an eye blink :)

I'm at the point where I'd need to leverage this meta.json business.
It first took me some time to figure I had to install it inside the input/ directory
after I instrumented the code I can see now that my file is read all right, but the corresponding {{foo}} replacements do not take place, and I am trying to figure out what it is that I do wrong

I guess there is some confusion in my mind as to what is expected in that dictionary. The doc at https://github.com/mixu/markdown-styles#metajson explains how to define variable repoUrl for files under input/foo; what about files at the toplevel right in input/ ?

I have tried various tricks for defining 'bar' like
{
"" : { 'bar' : 'value'},
"." : { 'bar' : 'value'},
'bar' : 'value',
'input' : { 'bar' : 'value'},
}

but apparently to no avail, the occurrences of {{bar}} all come up empty;
I can feel there is something I do just wrong but I can't spot it, can you please help ?

---

Besides, given this scoping mechanism, I would fancy there should be a means to define a given variable at different levels of the filesystem tree, with the most precise (the longest prefix) taking precedence, is it the case right now ?
I have net yet taken the step of splitting my inputs into subdirs, but if that feature was working as I describe I might go down this road later on.

Thanks again in any case

[iamdoron]

Hi,

I hope I understand your problem. You are trying to access a variable defined in the meta.json from a markdown. Can you write a bit more about your use-case? I just want to make sure I understand

@mixu - Correct me if I'm wrong- I see you changed it in 54682e3 . Maybe it can be resurrected as an optional feature (if it is indeed the intended use-case)

[parmentelat]

Hi guys; thanks for your feedback

apparently I was not clear enough; I am not trying to use a meta-variable from a markdown but simply from page.html, like I can see {{title}} is being used;
I did succeed to define an additional meta-variable in the markdown header with e.g.

title: my title
tab: tab-to-activate
---

and then to use {{tab}} in page.html

but when I want to define variable 'bar' for all the markdowns, using the meta.json above, I can't get {{bar}} to correctly instantiate in the resulting html

this is the intended use, right ?

[iamdoron]

Oh, now I understand. You're looking for a variable that can be shared across 'projects' (directories) something similar to a global constant.

The meta.json definition is specific for each input dir
as you can see in https://github.com/mixu/markdown-styles/blob/master/lib/merge-meta.js#L7 each file is extended with its project (directory) definitions in meta.json

[parmentelat]

OK, I had that right; but...
If I run

generate-md --input markdown

and I have an input file in markdown/index.md, what would be projectName key in this case ? As I said, I have tried '.', '', 'markdown', and nothing seems to be working..

thanks !

[iamdoron]

"index"

projectName: either the file name, or the folder name of this file

it's the file name when its parent dir is the input dir

[mixu]

hi @parmentelat - thanks for filing this issue. I improved the docs a bit around this, hope that helps. I do think that there would be room for improvement, specifically:

• there should be a way to set defaults that apply to all files, perhaps under the "*" key
• the metadata should cascade rather than being applied on a per-directory / per-file basis (e.g. abc/foo/bar.md should see the composite of "*", "abc", "abc/foo", "abc/foo/bar", and the file metadata rather than just having the metadata defined in "abc/foo").

The current implementation was mostly written to maintain compatibility with the 1.x version, but I'd be happy to merge an improved version (ideally with integration tests - since otherwise I'll have to write those)

[parmentelat]

Hi there

My proposal indeed aimed at a cascading scheme
However I am not familiar with past-to-present schemes so I cannot deal with legacy and backward compliance

In a nutshell, I would propose that the dictionary used to deal with file /a/b/c.md would be computed this way (using python style as I am more of a python guy :) :
. Starting with the meta['/'](or {})
. Merging in meta['/a'](or {} etc...)
. Merging in meta['/a/b'] ...
. Merging in meta['/a/b/c'] ...
. Merging in metadata from the file

This should be rather straightforward to write; I am willing to give this a try when I have a chance, but probably not before september or so...

Note that definitions in meta['a/b/c'] are specific to the file; but that these should be overridden by metadata from the file itself IMO, hence this order

That same scheme could apply to files at the root level (i.e. files right under the input directory) with no change at all.

As far as naming, one could also consider using instead - in the same order
. meta['']
. meta['a/']
. meta['a/b/*']
. meta['a/b/c']
. metadata from the file
which might feel a little clearer

Or any variation along these 2, again I guess rhe choice here is more about legacy than anything else.

Any pointer to how integration tests should be written could come in handy and would be greatly appreciated

Thanks for the feedback in any case --- Thierry
Sent from my iPhone

On 12 juil. 2015, at 05:54, Mikito Takada notifications@github.com wrote:

hi @parmentelat - thanks for filing this issue. I improved the docs a bit around this, hope that helps. I do think that there would be room for improvement, specifically:

there should be a way to set defaults that apply to all files, perhaps under the "" key
the metadata should cascade rather than being applied on a per-directory / per-file basis (e.g. abc/foo/bar.md should see the composite of "", "abc", "abc/foo", "abc/foo/bar", and the file metadata rather than just having the metadata defined in "abc/foo").
The current implementation was mostly written to maintain compatibility with the 1.x version, but I'd be happy to merge an improved version (ideally with integration tests - since otherwise I'll have to write those)

—
Reply to this email directly or view it on GitHub.

[mixu]

Sounds good to me - I think its OK to move away from the legacy mechanism (which was somewhat limited) since I think the migration will be fairly straightforward and I'm pretty sure the people who wanted to move to the 2.x releases have done so by now.

I like the second naming convention a bit more, since it's closer to how glob expressions are written. I probably won't have too much time to work on this soonish but it's good to have something specced out.

As for integration tests, this test can probably be extended a bit to cover the new cases https://github.com/mixu/markdown-styles/blob/master/test/integration.test.js#L71

[parmentelat]

Hi

I have just committed a proposal for implementing this feature in my own fork here
parmentelat@551e344

in essence:
. I have implemented the second naming scheme as per your preference
. I do not have anything test-related yet, but I did test this rather thoroughly on my own input website and am so far happy with what I can see

. I add a 'relative' property to each 'item' object (and do not use projectName in mergeMeta anymore at all)
. then mergeMeta does re-create the input 'item' object starting from an empty {} and adding values going down the file tree; then it adds the original 'item', and finally sets the title property from headings, if it's still missing, like it was done beforehand

I would appreciate a quick review; as I said I am not very fluent in JS so this might be a little awkward or tedious at times

[parmentelat]

as a final note

at first glance it might very well be that projectName was only used in merge-meta.js (apart from other references in test/) so it would make sense to remove the 8 lines that are about setting this property in set-output-path.js

like here
parmentelat@79479eb

[mixu]

published on npm as v3.0.0