Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Layout metadata should be combined to the document's #458

Open
ndastur opened this issue Mar 14, 2013 · 12 comments
Open

Layout metadata should be combined to the document's #458

ndastur opened this issue Mar 14, 2013 · 12 comments

Comments

@ndastur
Copy link

ndastur commented Mar 14, 2013

I use this construct in default.html.eco

<%- @getBlock('scripts').add(['/vendor/log.js', '/vendor/jquery-1.9.1.min.js', ].concat(@document.scripts or [])).toHTML() %>

in my default layout file. The purpose being to only include certain scripts for certain pages.

I then have a blog.html.eco layout which derives from default. I.e. with metadata


---
layout: default
scripts: ['/scripts/messages.js']

---

However, the scripts metadata item does not get parsed.

In order for this to work I have to put the scripts: metadata tag in every blog file

It would be great if the metadata sort if filtered up the chain


Want to back this issue? Place a bounty on it! We accept bounties via Bountysource.

@balupton
Copy link
Member

Agreed, I hit this issue recently. Should the docoument meta data take preference of the layout? So bottom takes preference?

@ndastur
Copy link
Author

ndastur commented Mar 15, 2013

I think so yes. There is a sort of chain.

It would be too complicated to combine the data I guess.

@balupton
Copy link
Member

I'll add it to the todo. The question now becomes when in the processing order should this occur? During rendering or prior? For example, we have to prevent the layout's layout meta data property overwriting the document's, which would only render the top-most layout.

@adam-p
Copy link

adam-p commented Sep 5, 2013

I also encountered this and found that it didn't behave the way I expected.

Agreed, I hit this issue recently. Should the docoument meta data take preference of the layout? So bottom takes preference?

This is what I expected, yes. (I can see from his example why @ndastur would like the values to be combined, but I don't think I'd reasonably expect that to happen.)

@balupton
Copy link
Member

balupton commented Sep 5, 2013

Thanks for that. Does this sound good? It is done during the contextualize process, and done in a bottom first (document first) and top last (layout last) merge style. That way we wouldn't be over-writing any meta data properties.

@adam-p
Copy link

adam-p commented Sep 6, 2013

I... don't think I can parse what you're saying? Perhaps an example?

This is what I'd expect (please note: I'm basically a Docpad newb):

layouts/default.html.eco:

---
first_value: default_first
second_value: default_second
---

layouts/page.html.eco:

---
layout: default
second_value: page_second
third_value: page_third
---

documents/about.html.eco:

---
layout: page
third_value: about_third
fourth_value: about_fourth
---
<%= @document.first_value %> <%= @document.second_value %> <%= @document.third_value %> <%= @document.fourth_value %>

Resulting about.html:

default_first page_second about_third about_fourth

I would expect the same if the content line were in the layout rather than in the document.

So, merging values, with document values having precedence over layout values, and layouts closer to the document having precedence over deeper ancestor layouts.

(For background: I'm in the midst of making an i18n-happy site and using https://github.com/OuiShare/ouisharefest as a reference. So the actual page content is in a layout and the documents are just shells that specify what language they should be in. So I want to be able to specify the title -- or, specifically, the title-translation-key -- just once in layouts/faq.html.eco rather than in documents/en/faq.html.eco and documents/ru/faq.html.eco, etc. But... I discovered I can't, and here we are.)

@balupton
Copy link
Member

balupton commented Sep 6, 2013

Yep, that output is what I would expect. Does that work for you?

@adam-p
Copy link

adam-p commented Sep 6, 2013

It works for me.

@trooney
Copy link

trooney commented Jan 15, 2014

Was this resolved? I'd could also use functionality mentioned here.

@RobLoach
Copy link
Contributor

This would be quite helpful. Merging of the meta data would make setting up content quite easy.

@Zearin
Copy link
Contributor

Zearin commented Apr 19, 2015

👍

1 similar comment
@marcusstenbeck
Copy link

+1

@balupton balupton added this to the Evaluate milestone Jul 20, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants