gma / nesta

File Based CMS and Static Site Generator
http://nestacms.com
MIT License
902 stars 121 forks source link

Access metadata on parent pages #140

Closed datenimperator closed 1 year ago

datenimperator commented 10 years ago

Page metadata should be available recursively. A page /blog should define a key Subpage header: Archive and any page below that (eg /blog/some-page) should be able to retrieve that value:

metadata('Subpage header', :recursive => true)
 => "Archive"

Also, metadata should be able to provide sensible defaults.

metadata('Nonexistant key', :default => 'foo')
 => "foo"
gma commented 10 years ago

My immediate thought is that recursive metadata adds an extra concept that a user needs to understand. Simplicity and transparency is is a core goal in Nesta, so I'm going to need to be sold on this.

That said, I'm open to being sold on it. I see from the patch that a motivation to do this could have been to define a layout for a section of the site. There are other ways to do this though (e.g. write a Ruby method that returns a layout based on a path, in your app.rb file).

Have you got any more use cases up your sleeve?

Also, I'm sorry I didn't reply to any of these sooner; I seem to have managed to disable all emails from GitHub somehow!

gma commented 10 years ago

(I'm also going to close this as I'm going to spend some time working through outstanding issues tomorrow, and being able to see what needs attention will be really useful, but that doesn't stop discussion from continuing)

datenimperator commented 10 years ago

While layouts is a good example, there might be more:

  1. Page metadata (like author) could be overridden on a per-path basis. Such values are retrieved from metadata, with app config and environment values being fallbacks.
  2. I tend to use metadata for stuff like contact addresses, page icons or header image names. It's very convenient to be able to inherit those values to pages below.

I try to avoid code customization where possible. That's why I think this concept is better (and simpler) than having a bunch of custom helper methods to do the same.

gma commented 10 years ago

Okay, thanks. I can see it's a powerful idea. I'm going to re-open and think about it some more. What do you think about defining (in the metadata) whether a given piece of metadata can be accessed by pages beneath it?

datenimperator commented 10 years ago

I don't think that's necessary. It depends on the caller, not the callee, but the latter is where it's defined. If I'd need recursive search, I ask for it using metadata(my_key, :recursive=>true) but default is not to search recursively.

gma commented 10 years ago

Just to let you know where I'm up to on this, I think I'd favour writing some simple helpers in app.rb that made it explicitly obvious what the rules were. With your recursive metadata, an author of a page (which might not be the developer, but could be a non-technical person) wouldn't necessarily be able to tell that the metadata they were writing would have implications on other pages, which is why I feel rules like this ought to be specified in Ruby methods.

What you're doing here is basically shared config for a group of pages for use in the templates, isn't it?

Thanks for explaining the use case. Always interesting to hear, and does impact the future direction even if I don't merge stuff…