Add support for title

[Sytten]

This adds support for title.
It's my first time working with functional macros and this is not a simple use-case so let me know if this can be improved.
The title is useful for enums because currently the generator for rust clients created a struct for each variant and name them like:

• my_enum_one_of_1
• my_enum_one_of_2
• etc

So with the title you can at least control the name of each variant structure. There is an open issue to actually produce an enum but it's not been worked on for a while OpenAPITools/openapi-generator#9497.

[juhaku]

It is pretty good. There are some of the extra fields that are not supported by far and adding support for them is a good thing though and title is one of them.

However this implementation seems bit overly complicated for ther purpose.

• The Struct in attr.rs file is for attributes supported on Component level.
• The UnnamedFieldStruct attr.rs file is for attributes supported on Component level of a unnamed struct components.
• The NamedField in attr.rs file is for attributes supported on a field level of a Component.

By creating another type for title seems superfluous and does not give the the combined error message to the users when they mistype the attribute for the Component.

Based on test in the code the Struct and UnnamedFieldStruct needs changes. Instead of creating another type for the parsing title one could just add following lines to the types.

#[derive(Default)]
#[cfg_attr(feature = "debug", derive(Debug))]
pub struct Struct {
    example: Option<AnyValue>,
    xml_attr: Option<XmlAttr>,
    title: Option<String> // add title to the existing struct same should be added to the UnnamedFieldStruct
}

// then in parse component attr struct
impl Parse for ComponentAttr<Struct> {
    fn parse(input: syn::parse::ParseStream) -> syn::Result<Self> {
        const EXPECTED_ATTRIBUTE_MESSAGE: &str =
            "unexpected attribute, expected any of: example, xml, title";
// ......
                "title" => {
                    struct_.title = Some(parse_utils::parse_next_literal_str(input)?);
                }
// ......

// then in to tokens struct
impl ToTokens for Struct {
// ....
        if let Some(ref title) = self.title {
            tokens.extend(quote! {.title(#title)});
        }
// ....
}

Then the same for UnnamedFieldStruct.

[Sytten]

The reason I didnt do that is that you don't want it printed at the same level depending on the use case for enums. I initially did as you wrote, but realized that the title was misplaced for the cases of variant_tokens because the variant is set as a property.

We might want to do more like the deprecated support, but I don't think going the route of title in the existing structs is super.
We could make it work if we put the props as pub so they can be removed depending on the usecase but it felt wrong.

[juhaku]

The reason I didnt do that is that you don't want it printed at the same level depending on the use case for enums. I initially did as you wrote, but realized that the title was misplaced for the cases of variant_tokens because the variant is set as a property.

We might want to do more like the deprecated support, but I don't think going the route of title in the existing structs is super. We could make it work if we put the props as pub so they can be removed depending on the usecase but it felt wrong.

Aah.. Right.. Okay then surely that is okay. I didn't figure out that at first. Yeah it otherwise would indeed endup on the underlying type of a property used as a variant. Which is indeed a wrong place for it in this context. Yeah it would feel wrong to me either. There is probably architectural improvements to be done regarding this in future so that the correct attributes would be contained in one place for the type and not becoming scattered too small pieces. Thanks for clarifying ❤️