Prepend to list param

[adlerfaulkner]

I am using and altering CSS and have noticed how the config files will frequently define an object with a list type parameter, for example here:
https://github.com/comake/community-server/blob/3b353affb1f0919fdcb66172364234eb59c2e3f6/config/app/init/default.json#L10-L16

Then subsequently they concat more items to the list type parameter in a different file, such as:
https://github.com/comake/community-server/blob/3b353affb1f0919fdcb66172364234eb59c2e3f6/config/identity/access/restricted.json#L16-L19

Is there any way to add items to the list parameter at the top of the list or a specific index or is it restricted to the order in which the config files are executed?

[rubensworks]

Adding entries to a parameter are indeed append-only, there's no way at the moment to influence the insertion order.
I'm sure @joachimvh would also be interested in this.

Related to #66

[adlerfaulkner]

Got it. Thanks @rubensworks

If this feature were to be added, maybe something like:

"ParallelHandler:_handlers:0": { "@id": "urn:solid-server:default:IdpContainerInitializer" }

Where 0 is the index in the list of handlers you want to add the item into?

Also, seeing #80 and in my search for anwsers to my question above, maybe it would be good to add more documentation about the syntax and usage of [ComponentName]:_[ArgName] within args of a component config. Or is there some documentation I about that I am missing?

[rubensworks]

Sure, additional docs are always welcome!

[renyuneyun]

Interested to see this discussion.
Are the two examples given by @adlerfaulkner used together? I mean, does one of them override or extend the other, and both are included/imported in the same file?

I saw in some places, that a parameter of a class C accepts a list. But the next behaviour is not understandable (undocumented):

• The configuration file A instantiates an object of C with some ID ID, and gives some arguments
• Another configuration file B instantiates an object of C with the same ID ID, and gives some different arguments.
• However, A imports B.

I'm confused by the behaviour, and would like to see if you found that this means A extends the configuration defined in B (i.e. the eventual configuration is the combination of lists in both A and B, where those in A is appended to the end of that in B).

Example illustration

A:

{
  ...
  "import": [
    "B"
  ],
  ...
  {
    "@id": "ID",
    "@type": "C",
    "my_par": [
      1,
      2
    ]
  },
  ...
}

B:

{
  ...
  {
    "@id": "ID",
    "@type": "C",
    "my_par": [
      3,
      4
    ]
  },
  ...
}

Then, if I use A, would the object be instantiated with parameter [1, 2], or [3, 4, 1, 2] (or [3, 4])?

[renyuneyun]

Thanks @rubensworks . So do they actually merge in such settings (but order undefined)?
If yes, then how about parameters only accepting one value/object?

[rubensworks]

So do they actually merge in such settings (but order undefined)?

Indeed.

If yes, then how about parameters only accepting one value/object?

Those should crash. Because the type-checker will detect that the given value is a list (or multiple value), while a param only accepts a single value.

[renyuneyun]

Those should crash. Because the type-checker will detect that the given value is a list (or multiple value), while a param only accepts a single value.

Thanks. That's interesting, because I found that they did not crash in my setting (mentioned in my reply to #66)...
Anyway, it's good to get confirmation that this is not expected.

[rubensworks]

This type checking was only added since CJS 5.x, perhaps you're not using latest yet?

[renyuneyun]

Ah, that's why. I was using that with Solid Community Server, which depends on CJS 4.5.