Range where .Params.id "in" : integer vs strings

I’m trying to build a Hugo site referencing Characters and Novels of a very famous series of french books.
Each characters is in different novels.
The pairing is made by ids (from a previous framework)
So in my novel front matter:

    ---
    title: La Fortune des Rougon
    id: 75928
    date: 2010-03-22T09:36:55+00:00
    novel_year: 1871
    novel_characters:
      - 75949
      - 75955
      - 75977
    ---

Just like the novels, the characters have an id param in their Front Matter. I use those id to pair them.

Now, to retrieve every characters from a novel I use the following:
{{ range where .Site.Pages "Params.id" "in" .Params.novel_characters }} This doesn’t work.

But

{{ range where .Site.Pages "Params.id" "in" (slice 75949 75955 75977 }} does work.

Problem is, when I look at .Params.novel_characters with a printf:

[]string{"75949", "75955", "75977", "76000" ... ]

It appears each item of the slice is wrapped into double quotes, making me think that even though I enter those ID as is in my front matter, they are retrieved as strings in the .Params.novel_characters slice.

So my range where tries to find integers in a slice of strings…

Any suggestion as to how to go around this behaviour without having to rebuild my Front Matter (I usually have characters in the hundreds, not three… :wink:

Thanks

Found the workaround…

{{ range .Params.rm_novel_characters }}
    {{ $.Scratch.Add "chars" (slice (int .))}}
{{ end }}

and then

{{ range where .Site.Pages "Params.id" "in" ($.Scratch.Get "chars") }}

Now I am wondering if the range where should not be agnostic of type, considering yaml and toml let us write both strings and integers without quotes.

1 Like

I have also noticed that. Oddly all Page params get casted as strings.

To add to that, the except same params when used as resources params, do not get string-casted.

(Moved my question to a separate post.)

Interesting. Front Matter is great but yaml and toml not forcing the use of quotes to define strings makes it hard to guess right the type of the value intened by the editor.
I don’t know if there is a confusion proof way to go :confused:

But it seemed to have done the correct “guessing” for resources.params. I am just curious why forced string casting is done for Page params.

Me too, I suggest you open a new discussion about just that. Will be easier to spot for everyone involved I suppose.

Done.

1 Like