Come together and refine project data format

[thiagodemellobueno]

Right now top level pages are an associative array with slugs:

'gathercontent': {
  'pages': {
    'home' : { … },
    'about-us': { … },
    …
 }

but children of pages, or components are arrays

'home': {
  'children': [ ... ],
  'components': […]
}

this is fine for lots of situations, but there are situations where having an enumerated object with keys would be better, eg:

'about-us': {
  'children': {
    'our-mission': {…},
    'the-team': {…}
 }
}

should we make both? should we use objects always and walk it differently? how does this play with maintaining proto-durps parity?

[soniktrooth]

When it comes to the Derps, the only way to identify any given piece of content is via an entity ID so unless we're maintaining a map of section => id somewhere then I don't know that we can do that. e.g.

{
    'our-mission': 24,
    'the-team': 15,
    'blah': 65
}

Where the numbers are entity ids of ¶s.

It's possible though we could just wipe out the contents of the ¶ field and recreate it every time we are updating Drupal from GatherContent. Therefore, the node id would stay the same but the content would change. The only problem area with this approach would be the notion of 'reusable' content because we wouldn't want to wipe out an entity that was referenced from another node.

[thiagodemellobueno]

Cool. Maybe we'll do a map, but for easy walking we can also have the structure.

We can eventually do a twig helper that's getItemById or whatever.

As far as populating Drupal from GC that's a little further ahead, lets not go full bore on that yet.

On September 29, 2017 6:21:12 PM EDT, Josh notifications@github.com wrote:

When it comes to the Derps, the only way to identify any given piece of content is via an entity ID so unless we're maintaining a map of section => id somewhere then I don't know that we can do that. e.g.

{
   'our-mission': 24,
   'the-team': 15,
   'blah': 65
}

Where the numbers are entity ids of ¶s.

It's possible though we could just wipe out the contents of the ¶ field and recreate it every time we are updating Drupal from GatherContent. Therefore, the node id would stay the same but the content would change. The only problem area with this approach would be the notion of 'reusable' content because we wouldn't want to wipe out an entity that was referenced from another node.

-- You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub: https://github.com/kalamuna/metalsmith-gathercontent/issues/5#issuecomment-333252683

[hawkeyetwolf]

Oooh, I like this. What about using Blocks? They are "re-usable" content, whereas Paragraphs are meant to be used in one place only. Therefore, the block IDs are more "permanent" where the Paragraphs IDs are kinda transient. It's on my rainy-day to-do list to add the Kalagraphs behaviour to blocks, too, so we have the full flexibility in both places (re-usable and page-specific content).

[thiagodemellobueno]

Gonna keep this open, even though there were some big changes to how we do things that kind of obviates it. But there are probably other plugings / enhancements that can benefit from this discussion.