Closed datenimperator closed 1 year 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!
(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)
While layouts is a good example, there might be more:
author
) could be overridden on a per-path basis. Such values are retrieved from metadata, with app config and environment values being fallbacks.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.
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?
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.
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…
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:Also, metadata should be able to provide sensible defaults.