using meta.json about markdown-styles HOT 11 CLOSED

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)

from markdown-styles.

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 ?

from markdown-styles.

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

from markdown-styles.

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 !

from markdown-styles.

"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

from markdown-styles.

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)

from markdown-styles.

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 [email protected] 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.

from markdown-styles.

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

from markdown-styles.

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

from markdown-styles.

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

from markdown-styles.

published on npm as v3.0.0

from markdown-styles.