Allow data.json inheritance at pattern group level

[tburny]

I am using Pattern Lab Node v2.7.1 on Linux, with Node v4.6.2, using the Grunt Edition.

Expected Behavior

Especially for patterns in the pages category it should be possible to override the global data.json with category-specific values. Pattern data can still override the data, so the chain should be _data/data.json → _source/patterns/pages/data.json → _source/patterns/pages/my-page.json where → means overridden by.
A use case is that there might be homepages with different brands. For instance there are (München Ticket) (http://muenchenticket.de) and Sueddeutsche Tickets (SZ) which share the same layout, but brands should be interchangable in the PL based on the data.json.
The advantage is that for SZ pages the JSON doesn't have to be defined for each and every SZ page.

Actual Behavior

Placing a data.json in a subfolder of patterns has no effect (unless there is a pattern named data.html of course).

[james-nash]

As you point out, there could be an (admittedly unlikely) naming clash if someone happens to have a pattern called data.

To avoid that, how about having the category-specific JSON file one level up like this:

|
+- 00-atoms/
|     |
|     +- 99-foo.mustache  # Usual stuff...
|     +- 99-foo.json
|     +- 99-foo.listitems.json
|     +- 99-foo.md
|
+- 00-atoms.json  # NEW data that can override root data.json for every pattern inside 00-atoms/
+- 00-atoms.listitems.json # NEW listitems equivalent of the above

This approach sort of mimics how per-pattern JSON files live next to the Mustache files they relate to, in that it puts the per-category JSON files next to the folder they relate to.

[bmuenzenmeyer]

To me, this is the sort of thing that, if we were to support it, we should build it correctly across platforms, or at least get it voted across both.

[tburny]

You mean for both PHP and Node?

[bmuenzenmeyer]

correct. I understand the utility, but wish to adhere to the conventions Dave and I put in place for making significant changes to the core experience.

https://github.com/pattern-lab/the-spec is the right place to debate this, in my opinion

[tburny]

@james-nash Maybe it would be a good idea to simply mimic the structure of _source/patterns subfolders in _data, e.g. _data/00-atoms/data.json (plus listitems). This way we still can have a _source/patterns/00-atoms/data.html pattern with no clashes.

[bmuenzenmeyer]

This approach sort of mimics how per-pattern JSON files live next to the Mustache files they relate to, in that it puts the per-category JSON files next to the folder they relate to.

worth noting, this is how markdown works too for sub-categories

[james-nash]

Seems sensible.

FWIW, an additional scenario where this is useful is the pages category, if you're (strictly?) following Atomic Design. For atoms, molecules, organisms and templates you might want to use lorem ipsum text and wireframe-like boxes as image placeholders - that's easily done via the root data.json and listitems.json. However, on pages you want to substitute those for example text and images. Since several things are often shared across several pages, having to copy-paste them into many individual patternName.json files is a chore.

This would be a more elegant solution IMHO since you'd override what you need to once, at the category level.

[james-nash]

@bmuenzenmeyer @tburny Happy to raise an issue for this over on the spec project, unless one of you is already doing that

[tburny]

Go for it 👍

[james-nash]

@bmuenzenmeyer Am I allowed to? It looks like all spec issues so far came from Dave Olsen or yourself. Don't want to be treading on anyone's toes :-)

[bmuenzenmeyer]

others are encouraged. only him or I may call a vote on the topic once we've figured out the details.
you will see the format of other spec enhancements

[james-nash]

Ok cool. Doing it now.

[james-nash]

@bmuenzenmeyer Done: pattern-lab/the-spec#31

I wasn't sure what to put for the timeline and tagging stuff at the bottom, so I've commented those bits out for now. Feel free to edit as you see fit (or tell me what to put in there).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.