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>
Objects and arrays are now optionally identified by their
'properties' or 'items' property if their 'type' is left
out.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
We now derive Serialize and Deserialize automatically.
This way we'll be able to add verifiers right into the
structs, support our 'rename' functionality, and our
'default' handling etc. which needs to be compatible with
what we have in perl.
Ideally this will also give us the option to mark structs as
being perl-compatible "property strings"
(PVE::JSONSchema::parse_property_string()) and automatically
derive FromStr for structs on demand.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
An `fn` type can be more annoying to produce in some generic
cases, and we haven't really needed it yet.
Signed-off-by: Wolfgang Bumiller <wry.git@bumiller.com>
Drop #!feature(specialization) in favor of having a `cli`
property for types to decide whether they are CLI
compatible.
The unconstrained_type! macro now has both ParseCli and
ParseCliFromStr in view, and requires one of the two to be
implemented for a type. This means that if a type implements
FromStr, it should "just work".
For types created without the help of the #[api] macro,
there's a shortcut to exclude a type from the CLI via
the no_cli_type!{typename} macro.
Signed-off-by: Wolfgang Bumiller <w.bumiller@proxmox.com>
