[pdm-devel] [PATCH datacenter-manager v3 02/18] lib: api-types: add 'layout' property to ViewConfig

[Shannon Sterz]

On Mon Nov 24, 2025 at 11:14 AM CET, Dominik Csapak wrote:
>
>
> On 11/24/25 10:55 AM, Dominik Csapak wrote:
>>
>>
>> On 11/17/25 3:57 PM, Shannon Sterz wrote:
>>> On Mon Nov 17, 2025 at 1:44 PM CET, Dominik Csapak wrote:
>>>> this is a simple string that holds the layout json. We can't currently
>>>> add it as a normal property with 'correct' api types, since we want to
>>>> use enum features that are not available with the api macro.
>>>>
>>>> Signed-off-by: Dominik Csapak <d.csapak at proxmox.com>
>>>> ---
>>>>   lib/pdm-api-types/src/views.rs | 12 +++++++++++-
>>>>   server/src/views/tests.rs      | 15 +++++++++++++++
>>>>   2 files changed, 26 insertions(+), 1 deletion(-)
>>>>
>>>> diff --git a/lib/pdm-api-types/src/views.rs b/lib/pdm-api-types/src/
>>>> views.rs
>>>> index ef39cc62..4b837384 100644
>>>> --- a/lib/pdm-api-types/src/views.rs
>>>> +++ b/lib/pdm-api-types/src/views.rs
>>>> @@ -47,7 +47,10 @@ pub const FILTER_RULE_LIST_SCHEMA: Schema =
>>>>           "exclude": {
>>>>               schema: FILTER_RULE_LIST_SCHEMA,
>>>>               optional: true,
>>>> -        }
>>>> +        },
>>>> +        layout: {
>>>> +            optional: true,
>>>> +        },
>>>>       }
>>>>   )]
>>>>   #[derive(Clone, Debug, Default, Deserialize, Serialize, Updater,
>>>> PartialEq)]
>>>> @@ -67,6 +70,13 @@ pub struct ViewConfig {
>>>>       #[serde(default, skip_serializing_if = "Vec::is_empty")]
>>>>       #[updater(serde(skip_serializing_if = "Option::is_none"))]
>>>>       pub exclude: Vec<FilterRule>,
>>>> +
>>>> +    // we can't currently describe this with the 'api' macro so save
>>>> +    // it simply as a string and check it in the add/update call
>>>
>>> one question: shouldn't this be `Value` instead? right now this needs to
>>> be a string that is valid json. meaning that the api expects a json body
>>> that contains `layout` as a string, with that string being escaped json
>>> again.
>>>
>>> with `Value` this could be the json directly, avoiding having to escape
>>> the json string. this would also make it easier to describe this later
>>> on via the api macro if i'm not mistaken. the last commit in this series
>>> could then also be dropped.
>>>
>>> what do you think?
>>
>> had a short look and it seems like that we can't currently combine
>> the Updater derivation with Value since there is no
>> impl of UpdaterType/ApiType for Value and we can't provide one.
>>
>> i shortly tried to implment a wrapper type, but then we run into
>> the issue that we'd have to impl ApiType for that too and
>> the fact that we can't currently represent the Layout in a schema is
>> the whole point of the string workaround here.
>>
>> The only thing that could work here is to simply define
>> an ObjectSchema with no properties and 'additional_properties' to true.
>> I'll try that and see if it makes the situation better.
>>
> ok this won't work AFAICS since the section config currently only
> does a 'parse_simple_value' which can't handle object schemas
>
> so i think using strings here is currently the best way to handle
> this (besides making section config have complex types in its values
> instead of just 'simple' values. but this seems a bit out of
> scope for this for now?)

yes that's fair. i didn't have the time to explore potential options
here. i suppose we can leave it as-is for now if there are no sensible
alternatives. might be nice to collect the different approaches
discussed here and why they fall short in the commit message or its
notes, though.