The description comes from the doc comment, the field types
and description from field doc comments and types.
Previously we needed to add at least the hint that the
schema is an object schema. Now we support an empty #[api]
attribute as well.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
infer_type now also returns whether it was encapsualted in
an Option<>. So `type: String, optional: true` is now
inferred propertly from `Option<String>`.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
The function attribute reader doesn't read any other
attributes anymore, so make it reusable!
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
Initially it was a wrapper around Ident to avoid some
copies, but now it's what we use to allow hyphenated names
for fields in objects (as `syn::Ident` doesn't allow that at
all), so give it a more fitting name.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
The user must always be explicit about whether the Ident or
the String is required, since they may differ.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
See the test example:
assuming a `pub struct Foo` which implements `Serialize` and
`Deserialize`, we also expect it to provide a
`pub const Foo::API_SCHEMA: &Schema` like so:
#[derive(Deserialize, Serialize)]
pub struct StrongString(String);
impl StrongString {
pub const API_SCHEMA: &'static Schema =
&StringSchema::new("Some generic string")
.format(&ApiStringFormat::Enum(&["a", "b"]))
.schema();
}
Then we can use:
#[api(
input: {
properties: {
arg: { type: StrongString },
}
},
...
)]
fn my_api_func(arg: StrongString) -> Result<...> {
...
}
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
We may want to add the ability to declare a Schema for
structs, so factorize function handling into its own file.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
The json value type is more of an intermediate step between
the TokenStream and the Schema type and should stay somewhat
independent of it. We may want to reuse it for the router?
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
enum Foo {
Variant1(Type), // allowed
Variant2(Type, Type), // not allowed
Variant3 { name: Type }, // not allowed
}
In the simple case of a single type we simply drop the
automatically derived `FromStr`/`Display` impls and expect
the user to implement them manually, while in the `verify()`
method we simply match on self and forward to the inner
verifier.
So to get "tagged unions" in the API, implement a proper
API type for each variant, then add an enum with 1-tuple
variants.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
In PVE we have multiple different enum types: hyphenated,
all-caps, underscores.
By default our api-macro enums will convert CamelCase to
underscores, so we need a way to represent the rest:
enum AnEnum {
CaseOne, // becomes "case_one",
#[api(rename = "case-two")]
CaseTwo, // "case-two",
#[api(rename = "CASE_THREE")]
CaseThree,
}
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
