Generated types that use enums have wrong parameters

[Harkonn]

Bug Report

Q	A
BC Break	yes/no
Version	4.4.1

Summary

The generated types that use an enum of type string create a fatal error exception:

Got error 'PHP message: PHP Fatal error:  Declaration of namespace\\Type\\CodeNachrichtAntwortCode::getCode(): namespace\\Type\\CodelisteNachrichtAntwortCode must be compatible with namespace\\Type\\Code::getCode(): string

Current behavior

The generated code for the complexType Code.NachrichtAntwortCode has an element named code of type xzufi:Codeliste.NachrichtAntwortCode in the imported schema xzufi-baukasten.xsd (which itself is imported in xzufi-leistungen.xsd). It is an enumeration of strings and the following type gets generated:

enum CodelisteNachrichtAntwortCode: string {
    case Value_000 = '000';
    case Value_001 = '001';
    case Value_101 = '101';
}

The get- and with-methods want to have an object of this type:

class CodeNachrichtAntwortCode extends Code
{
    // stripped code
    /**
     * @return namespace\Type\CodelisteNachrichtAntwortCode
     */
    public function getCode() : namespace\Type\CodelisteNachrichtAntwortCode
    {
        return $this->code;
    }

    /**
     * @param namespace\Type\CodelisteNachrichtAntwortCode $code
     * @return static
     */
    public function withCode(namespace\Type\CodelisteNachrichtAntwortCode $code) : static
    {
        $new = clone $this;
        $new->code = $code;

        return $new;
    }

}

My IDE is already complaining about these types (Return type declaration must be compatible with Code->getCode() : string ). Also the real values are just the strings in the soap-communication:

<xzufi:antwortrueckgabecode listURI="urn:xoev-de:fim:codeliste:xzufi.nachrichtantwortcode" listVersionID="1.1">
	<code>000</code>
</xzufi:antwortrueckgabecode>

How to reproduce

1. Run ./vendor/bin/soap-client generate:types --config config/soap-client.php for https://xzufi-v2-2-0-nw-schul.infodienste.de/?wsdl (warning: it will generate 1400 files...)
2. Look into the type for CodeNachrichtAntwortCode.php and see that the method getCode() returns \namespace\Type\CodelisteNachrichtAntwortCode and withCode expects \namespace\Type\CodelisteNachrichtAntwortCode

Expected behavior

The generated values for the get- and with- methods should be of the type of the enums (in my case string) instead of expecting the generated-enum-type class as a value.

[veewee]

Thanks for reporting @Harkonn.

Oof, this will be a hard one to crack...
The generated code is as expected, but it is just not valid in PHP.

Base type:

<xs:complexType name="Code">
    <xs:sequence>
      <xs:element name="code" type="xs:token" form="unqualified"></xs:element>
    </xs:sequence>  
</xs:complexType>

Extending implementation:

<xs:complexType name="Code.NachrichtAntwortCode">
    <xs:complexContent>
      <xs:restriction base="xoev-code:Code">
        <xs:sequence>
          <xs:element form="unqualified" name="code" type="xzufi:Codeliste.NachrichtAntwortCode">
          </xs:element>
        </xs:sequence>
    </xs:complexContent>
</xs:complexType>


<xs:simpleType name="Codeliste.NachrichtAntwortCode">
    <xs:restriction base="xs:token">
      <xs:enumeration value="000"></xs:enumeration>
      <xs:enumeration value="001"></xs:enumeration>
       <!-- ..... -->
    </xs:restriction>
</xs:simpleType>

As you can see:

• the base type is expecting a string
• the concrete implementation is expecting an enum

For XSD, enum is just a string. But in PHP, an enum is an object and not a string.

The only thing I can think of, is to provide a configuration option to disable enum generation alltogether so that you can disable it, but that wouldnt really make it easy to use.

An alternative, is for you to create a metadata manipulator that changes the base-type "code" property to mixed instead?

[Harkonn]

Thank you for your help @veewee . I'm sorry for the late response.
I am trying your suggestion with the metadata manipulator, but i can't get it to work. It does not change the generated types.
I used:

<?php

namespace Xzufi;

use Phpro\SoapClient\Soap\Metadata\Manipulators\TypeReplacer\TypeReplacer;
use Soap\Engine\Metadata\Model\XsdType;
use Soap\WsdlReader\Metadata\Predicate\IsOfType;
use Soap\Xml\Xmlns;

final class XzufiManipulator implements TypeReplacer
{
    public function __invoke(XsdType $xsdType): XsdType
    {
        $check = new IsOfType('http://xoev.de/schemata/xzufi/2_2_0', 'Code');
        if (!$check($xsdType)) {
            return $xsdType;
        }

        return $xsdType->copy('Code')->withBaseType('mixed');
    }
}

Could you please give me a hint into what to replace in this complex structure?

Also, there seems to be old code in your linked documentation. The line

return Config::create()
    //...
    ->setTypeReplacements(
        TypeReplacers::defaults()
            ->add(new MyDateReplacer())
    )
    // ...

should use setTypeReplacementStrategy instead of setTypeReplacements.

[Harkonn]

Okay, i made some progress. I can set the type to mixed now, but this results in bad code completion results because every usage of the base-"Code" is being set to mixed only. Maybe there is a good middle ground.
This is my code now:

public function __invoke(XsdType $xsdType): XsdType
    {
        $check = new IsOfType('http://xoev.de/schemata/code/1_0', 'Code');
        if (!$check($xsdType)) {
            return $xsdType;
        }

        return $xsdType->copy('mixed');
    }

[veewee]

Just thinking out loud:
What if you would set the type to \BackedEnum::class?

[Harkonn]

I tried your idea and played around with the TypeReplacer, but i don't get it to work the way it should. Maybe a part of this is totally unneeded.
All of the problematic classes extend the class Code, which has the property code as string.
Each extended class has its own specialized backed enum, for example CodeNachrichtAntwortCode extending Code has the enum CodelisteNachrichtAntwortCode as property code or CodeKostentyp extending Code has the enum CodelisteKostentyp as property code.
By extending the base class Code changing the property code type from string to enum is the problem.

I looked at all the classes that extend Code and all of them have implemented everything that the base class offers themselfes. All properties, get and with-methods. I don't know why they get generated that way, but i can just remove that inheritance and i loose nothing and keep the typesafety for these classes and properties.

I am not sure if this is the bug in the generation but if it is not i would like to just remove the extending of the class.
But i did not get it to work with the TypeReplacer.

What do you think?

[veewee]

@Harkonn if disbling the ExtendingTypeAssembler works for you, then that would be a fine solution.

The generated class indeed contains all properties inherited from the parent class.
The extension is there for if you rely on e.g. any "Code" object instead of a specific implementation.
But if you are not relying on that, then this would be a good idea to overcome the issue.

[Harkonn]

Thank you @veewee. I testet this and disabled the ExtendingTypeAssembler. It should fix the string / enum indifference, but other code parts are broken now. For example SuchprofilLeistung extends Suchprofil without extending is now missing the property id.

The generated class indeed contains all properties inherited from the parent class.

I missunderstood this as a more generell way phpro/soap-client generates code for classes that extend other classes.

Is there a way to just disable ExtendingTypeAssembler for classes that extend Code?

[veewee]

Is there a way to just disable ExtendingTypeAssembler for classes that extend Code?

Yes, you'dd have to write your own rule for this.
Currently you are probably using the rule IsExtendingTypeRule. You can use that as a base and add or decorate code to detect wether the type contains the code.

I still think extending the base-type to \BackedEnum might be a better idea. Would that solve static analysis? (you can try this by changing it manually and run your analysis)
If so, I can help building a type replacer.

[Harkonn]

I tried to do it manually like you suggested and i changed the code for Code.php to use \BackedEnum instead of string for $code:

<?php

namespace namespace\Type;

class Code
{
    /**
     * In diesem XML-Element wird der Code einer Codeliste übermittelt.
     *
     * @var \BackedEnum
     */
    private \BackedEnum $code;

    // Some stripped Code

    /**
     * @return \BackedEnum
     */
    public function getCode() : \BackedEnum
    {
        return $this->code;
    }

    /**
     * @param \BackedEnum $code
     * @return static
     */
    public function withCode(\BackedEnum $code) : static
    {
        $new = clone $this;
        $new->code = $code;

        return $new;
    }
}

It still gives me PHP exceptions:
Got error 'PHP message: PHP Fatal error: Declaration of namespace\\Type\\CodeNachrichtAntwortCode::withCode(namespace\\Type\\CodelisteNachrichtAntwortCode $code): static must be compatible with namespace\\Type\\Code::withCode(BackedEnum $code): static in filepath/src/Type/CodeNachrichtAntwortCode.php on line 54'

Maybe i missunderstand something.

[veewee]

Ah yes, the function override will crash in that case indeed.
Didn't though about that ...

I've played around with it and think removing the extend from the types extending from code is the easiest thing to do (through a type replacer):

use Phpro\SoapClient\Soap\Metadata\Manipulators\TypeReplacer\TypeReplacer;
use Soap\Engine\Metadata\Model\TypeMeta;
use Soap\Engine\Metadata\Model\XsdType;

$config
    ->setTypeReplacementStrategy(
        TypeReplacers::defaults()
            ->add(new class implements TypeReplacer {
                public function __invoke(XsdType $xsdType): XsdType
                {
                    if ($xsdType->getMeta()->extends()->isSomeAnd(
                        static fn (array $extends): bool => $extends['namespace'] === 'http://xoev.de/schemata/code/1_0' && $extends['type'] === 'Code'
                    )) {
                        return $xsdType->withMeta(static fn (TypeMeta $meta): TypeMeta => $meta->withExtends(null));
                    }

                    return $xsdType;
                }
            })
    )

(Note that you will fetch latest engine, I discovered a bug: php-soap/engine#24)

---

The only way to fix this from our side is to introduce an option to stop using enums as properties / parameter types and fallback to the underlying type of string|int. I don't think this is a good solution since it forces implementations of the client to do the parsing back from / transforming into the enum manually from the user's side.

[Harkonn]

Wow, thank you @veewee ! Your code solved the problem and looks very clean. Maybe consider putting this code to your examples.. I would not have come up with anything like that from reading all these different documentations in your projects (which i find very usefull, so thank you again!).
I also think that this solution is good. I need to document why we change this type in the process of generating the files, but i do not need to touch the implementations this way. I also like this approch more.