Resources metadata rule ordering

support
#1

I’m trying to get my head around resources metadata rules and their ordering.
I understand from the doc that we should start by the more precise rule and then add the broader ones otherwise detailed rules will be overwritten.

Here is what I have:

resources:
- src: documents/guide.pdf
  title: Instruction Guide
  params:
    ref: '90564568'
- src: documents/checklist.pdf
  title: Document Checklist
  params:
    ref: '90564572'
- src: documents/photo_specs.pdf
  title: Photo Specifications
  params:
    ref: '90564687'
- src: documents/payment.docx
  title: Proof of Payment
- src: 'documents/*.pdf'
  params:
    icon: 'pdf'
- src: 'documents/*.docx'
  params:
    icon: 'word'

In this exemple it appears that only document/payment.docx will end up with the proper icon. All the others won’t. It is like the different rules’ “params” object is not merged but overwritten complety.
So only the resource with no params in its detailed route gets the right icon.

Is this by design ? I’m sure it makes sense somehow and I overlooked something, but I appear a bit lost here :wink:

1 Like
#2

Hey again :slight_smile:

This looks like a bug… looks like once any params is set for a file, it’s not possible to add more params for that file.

I quickly came up with 2 test cases that shows this issue, using the example files from your blog post.

This behavior makes sense for name and title. But for params where new user-defined parameters can be added in step-wise src lines, the behavior feels wrong.

Update (2018/01/23): I confirm the param merging feature in Hugo PR # 4316. The Hugo Output links in the above test cases now show the outputs created using that PR build. Thanks @bep!

#3

As I have mentioned in other placing: There is no merge logic, so the first name, title and params win.

#4

It would be nice to be able to merge though. It makes the managing of the params attributes very difficult for complex bundles… :thinking:

#5

There is no merge logic

Oh, looks like then this (below) is the only way…

#6

I’m not sure that can be expressed in a non-ambiguous way with the current syntax. I understand your particular example, but that is a fairly simple one. If someone can describe and implement a working “merge logic”, I will merge.

#7

I can take one quick example:

src = "*.jpg"
params
license = MIT
photographer = bep

src = "*.*"
params
author = bep

A stupid example, perhaps (I’m sure it is possible to think of more real cases). But if a blind merge like suggested the above would not be correct.

#8

Why not?
So a jpg image would end with:

.Params.licence = MIT
.Params.photographer = bep
.Params.author = bep

What’s wrong with that?

1 Like
#9

I agree with that.

@bep One should be using the correct globbing pattern for src. Is author wasn’t meant to be applied to all files, then *.* shouldn’t have been applied.

On another note, even if some params are applied to unintended files, user has another level of control at the time of using those params via .Match… example: OK… author got applied to *.*… but then the user can choose to print the author on the page only for the set .Match glob. WDYT?

#10

The PNG (non JPEG) resources will get values that do not belong there.

  1. The params is a value (the whole set)
  2. A value is only set if not already set by some rule higher up

I will probably come up with a better example, but you cannot currently blindly merge the params maps without additional information.

#11

I’m not sure I follow. There must be something I’m not catching.
But if you have time for a better exemple, that would be great.

#12 
src = "*secret*.doc"
params
someparam = "some value"

src = "*.doc"
params
username = "bep"
password = "password1234"

Maybe still a stupid example, but if I blindly merge the params map I would:

  • get values for the secret docs that I don’t want
  • you could argue that I should not have included “secret” in the second matcher, but how do I do that? I assume there are some negative matching possible here, but …
#13

If the user has defined the src = "*.doc" rule then he should expect all of his doc files to hold username and password.

And he should expect any doc file with “secret” in his name or path to have someparams as well.

This is the behaviour I expect, and cannot see the harm in that :frowning:

What I don’t expect is to lose the username and password params I defined for all of my doc files, simply because one of those doc needed an extra param.

I am sorry I cannot see the problem here. Maybe someone else can help me :thinking:

#14

Extending the same example, one can even have:

src = "*secret*.doc"
params
someparam = "some value"

src = "*Secret2*.doc"
name = "secret2-:counter"

src = "*.doc"
params
username = "bep"
password = "password1234"

Under the current behavior, the username and password would apply to "*Secret2*.doc" too! That also doesn’t look like the right behavior.

The solution is simple: The user should be careful when assigning parameters using blanket globs like *.*, *.jpg, etc.

The current logic that once name and title are set, they shouldn’t be set again makes sense. The suggestion is that that same logic be applied inside something like {{ range .Params }} instead of to the whole of .Params.

#15

That is well defined behaviour and easy to work around. Your suggested change is extremely hard to wrap your head around if you have many rule sets, and it is ambiguous.

This is not about leaking secrets (I knew my example was bad).

With your suggested change I have no easy way to apply one parameter set to “mypattern.jpg” and another different default parameter set to the other images.

You can easily solve the other problem by duplicating the icon parameter etc.

So, the current solution may be sub-optimal for this particular use case, but at least it doesn’t break if you look hard at it.

#16

But let’s sleep on it … :slight_smile:

1 Like
#17

Thank you :slight_smile:

With your suggested change I have no easy way to apply one parameter set to “mypattern.jpg” and another different default parameter set to the other images.

I am still struggling to understand why that is hard… one can easily plan ahead and have something like:

src = "*.jpg"
params
foo = "some param specific to JPEGs"

src = "*.pdf"
params
bar = "some param specific to PDFs"

Now if you enable param merging, it would be nice to have:

src = "*.[pj][dp][fg]"
params
zoo = "params common to .pdf and .jpg (and .ppg, pdg, .. ;-))"

It feels like we are talking about the same thing, but in one approach A is easy, B is difficult; and in the other approach A is difficult, B is easy… but both A and B are achievable in both approaches. You approach is to implicitly create filter sets for params. My approach is to let the user manually create filter sets using src.

#18

Sure, but what with:

src = "*noboo*.jpg"
params
foo = "some param specific to noboo JPEGs"

src = "*.jpg"
params
foo = "some param specific to JPEGs"
boo = "some other param"

So in the noboo case I do not want the boo value. How do I do that? You may argue that I can just ignore/throw it away, but I how do I do that if I just loop the key/values?

#19

I cannot think of a real use case like that. I would just plan ahead and name the files appropriately (may be put files in boo/ subdir vs noboo/ subdir) if any such kind of mutually exclusive parameter assignment needs to happen. So it’s back to the usecase-per-user problem. The problem you are seeing doesn’t apply to me, and the problem I am seeing doesn’t apply to you :slight_smile:

#20

I see the use case you are referring too, but cannot identify with it.

I want to easily assigne params to mulitple resources. For me it seems the be the priority. Having to copy/paste the icon params for my exemple above doesn’t really make sense.

Having to be aware that noboo inherit the boo param no matter what is something I can live with. I could still overwrite it with boo = false if that comes to it.

But again, that is just one opinion. I think we need more.