Is there an elegant way to dynamically include a page's Type and / or Layout in a params lookup?

[Wolfspyre]

I’m uncertain if this functionality already exists… and …if it doesn’t …if it’s even a good idea.

I’d think that it would be beneficial to be able to express something like the following look-up/look-through behavior:

$featureToggle := .Params.featureToggle | default .Site.Params.$LAYOUT.$TYPE.featureToggle 
                                          | default .Site.Params.$TYPE.featureToggle
                                            | default .Site.Params.featureToggle
                                              | default false

The desire/idea being:

'I THINK I would like to be able to set parameter defaults for a thing at the:

• section+type

and

• type

levels
and then be able to perform a dynamic lookup from a partial template which could be included from multiple depth hierarchies
and have the partial be able to grab the most relevant config value for the context in question’

Now, I’ll concede that it is ENTIRELY POSSIBLE (if not likely) that this isn’t that great an idea …because reasons I don’t yet understand…

but it seems like this would follow the established hierarchy of template lookups,

Template lookup order

Does my question make sense?

assuming I’ve managed to convey the question grokably…

is this

• already possible, and thoroughly documented, and I’m just dense?
• already possible, but not terribly well documented, because it’s kinda not the greatest idea.
• not currently possible, might be a good idea but not a priority to implement?
• a terrible idea?

TIA y’all.

Thanks for being such a great community of helpful peeps.
With all the crap going on in the world around us, it’s legitimately refreshing to see such vibrant, helpful communities thriving.

W

[jmooring]

See https://gohugo.io/content-management/front-matter/#front-matter-cascade

Set default color in site config:

[params]
color = 'defaultcolor'

content structure

content/
├── posts/
│   ├── section/
│   │   ├── _index.md <-- cascade color to all pages in section
│   │   ├── bar.md    <-- set color for this page
│   │   └── foo.md    <-- set color for this page
│   ├── _index.md     <-- cascade color to all pages of this type
│   └── post-1.md     <-- set color for this page
└── _index.md

Then in template call:

{{ .Param "color" }}

Precedence:

1. Page
2. Section
3. Type
4. Site default

Example:

git clone --single-branch -b hugo-forum-topic-47385 https://github.com/jmooring/hugo-testing hugo-forum-topic-47385
cd hugo-forum-topic-47385
hugo server

You can also define your “cascades” in site configuration, using cascade.target to target by path.

[Wolfspyre]

Hi Joe!

Yeah, I’m familiar with cascade;

I was essentially wondering if there was an equivalent from the other-side of the lookup.

cascade facilitates inheriting front-matter attributes from parents,

I was figuring that the inverse
IE: being able to resolve values hierarchically.

might also be a thing and I’ve not been able to find it.

You’re always so helpful.
Thank you.

Cascade will absolutely work if this is the least messy way to address the expressed need…

AND

I’m curious as to why the inverse is a terrible idea (my words)

is interpolation not possible within the context of a lookup key?

or is there something I should search for on derInterwebs to get a better understanding of why this is problematic?

hope you’re having a great day!
you’ve certainly helped mine.

[jmooring]

Sorry, I misunderstood. You want the inverse of a cascade, meaning that a content creator cannot override a site/type/section parameter at the page level.

If this is for yourself I suppose that’s fine, but I wouldn’t create a theme with this behavior because it is unexpected.

If you want to go top-down instead of bottom-up, you could use site.Params falling back to site.GetPage.

[Wolfspyre]

hm… That’s not quite what I mean either…

lemme try this horrible example

...
{{-  $lItch := newScratch -}}
{{-     $lItch.Set "debug"     ( $scope.debug |default true)  -}}
{{-     $lItch.Set "logPrefix" "[articles/list]" -}}
{{-     $lItch.Set "debugPrefix" (print "[DEBUG]" ($lItch.Get "logPrefix") "[" .Page.File "] "  ) -}}
{{- /*  Breadcrumbs */ -}}
{{-     $lItch.Set "breadcrumbs" nil -}}
{{-     $lItch.Set "breadcrumbs" (.Params.showBreadcrumbs 
                                  | default (.Site.Params.articles.list.showBreadcrumbs 
                                    | default (.Site.Params.list.showBreadcrumbs 
                                      | default false))) }}
{{-     if ($lItch.Get "debug") -}}
{{-       warnf "%s breadcrumbs: %s" ($lItch.Get "debugPrefix") ($lItch.Get "breadcrumbs")  -}}
{{-     end -}}
{{- /*  CardStyle  */ -}}
{{-     $lItch.Set "cardStyle"  nil -}}
{{-     $lItch.Set "cardStyle" ( .Params.cardStyle 
                                 | default .Site.Params.articles.list.cardStyle
                                   | default .Site.Params.list.cardStyle 
                                     | default "graphic" ) -}}
{{-     if ($lItch.Get "debug") -}}
{{-       warnf "%s CardStyle: %s" ($lItch.Get "debugPrefix") ($lItch.Get "cardStyle")  -}}
{{-     end -}}
{{- /*  CardView  */ -}}
{{-     $lItch.Set "cardView"  nil -}}
{{-     $lItch.Set "cardView" ( .Params.cardView 
                                | default .Site.Params.articles.list.cardView 
                                  | default .Site.Params.list.cardView 
                                    | default "basic" ) -}}
{{-     if ($lItch.Get "debug") -}}
{{-       warnf "%s CardView: %s" ($lItch.Get "debugPrefix") ($lItch.Get "cardView")  -}}
{{-     end -}}

in this bit of … insanity…
the layout articles and the type list are hardcoded.
I was hoping for a way to express them as variables and have the site params object searched with the layout and type relelvant to the page/construct being generated in their place.

does that make more sense?

(is there a better way I should have expressed this question so as to be more easily grokable?)

[jmooring]

@Wolfspyre

layout articles and the type list are hardcoded.

Both are accessible via page methods. Page.Type returns the .Type, regardless of whether inferred from top-level section or defined in front matter. .Page.Layout returns the layout defined in front matter (if any), otherwise returns an empty string.

I’d create a partial for this.

[Wolfspyre]

layout is a refined semantical descriptor / label for Kind, right?

(It does make a lot more sense to me, type/kind were always getting mixed up in my head… layout is indeed more intuitively associative to the construct imo.)

or am I getting things even MORE muddled in my head again?

[jmooring]

@Wolfspyre

layout is a refined semantical descriptor / label for Kind, right

No.

https://gohugo.io/methods/page/layout/

https://gohugo.io/templates/lookup-order/#target-a-template

[Wolfspyre]

okay. I think I get it…

One can use layout to generate content via a specific template.

Kind is associated with a page based on its location in the hierarchy unless specified as something else in front matter.

They both influence rendering template choice though, right?

[jmooring]

@Wolfspyre

Kind is associated with a page based on its location in the hierarchy

No.

https://gohugo.io/getting-started/glossary/#page-kind

@Wolfspyre

They both influence rendering template choice

Yes.

[Wolfspyre]

@jmooring

No.

Glossary of terms | Hugo

sigh

Kind

this is wot I meant by “associated based on its’ location in the hierarchy”

the _index.md page within a first-level subdir of content ( books/ in the example here) will have a kind value of section
and the template used to render that page’s content would be a list or a section template

the book-2.md file would have the kind page and would default to a single template…

if the directory matches a taxonomy key name specified in the taxonomies config file, then that page will have a kind value of taxonomy and would default to a list template for rendering…

however, if specified in front matter, layout will override the default template association, yes?

IOW: layout is a handle to more explicitly declare the rendering template of a given bit of content… (but doesn’t change the underlying page’s Kind)

[jmooring]

@Wolfspyre

be a list or a section template

Yeah, those terms are sort of interchangeable. To me, “list” includes section, taxonomy, term, home, sitemap, and rss.

@Wolfspyre

layout will override the default template association

Yes. So will Type and Type + Layout.

@Wolfspyre

doesn’t change the underlying page’s Kind

Correct. Kind is immutable.