Different destination dir when generating using 3.2.7 VS 4.1.1 ??

[mwolff-fn]

Hi,

I was using the PackageGenerator via wsdltophp.phar in version 3.2.7 before and now I joyfully discovered that I can now install the latest version via Phar, so I did that, upgrading to 4.1.1.

Now, when I run the generator using the exact same settings as before, the directory structures of the generated files will be completely different. Suppose I run this command with wsdltophp.phar 3.2.7 (additionally, the "standalone" option is set to false in wsdltophp.yml):

wsdltophp generate:package --urlorpath="./resources/SERVICE.wsdl" --destination="./proxy/soap/$SERVICE" --namespace="My\\Namespace\\Proxy\\Soap\\SERVICE" --force --verbose

...then I will get the following directory structure:

/project_root
  /proxy
    /soap
      /SERVICE
        /Enum
          ...enum class files...
        /Service
          Service.php
        /Struct
          ...struct class files...
        ClassMap.php
        tutorial.php

...and all class files will be generated with the namespace prefix "My\Namespace\Proxy\Soap\SERVICE", followed by the category name (e.g. "\Service", "\Enum", "\Struct").

If I wanted to generate proxy classes for multiple services, I just need to point Composer's autoloader to /proxy/soap for all namespaces beginning with My\Namespace\Proxy\Soap and I'm done.

Now, if I re-generate the proxy classes using the exact same configuration with the wsdltophp.phar version 4.1.1, then I'm getting this directory structure instead:

/project_root
  /proxy
    /soap
      /SERVICE
        /My
          /Namespace
            /Proxy
              /Soap
                /SERVICE
                  /Enum
                    ...enum class files...
                  /Service
                    Service.php
                  /Struct
                    ...struct class files...
                  ClassMap.php

So basically, the generator now uses the initial destination dir as a base and appends the whole namespace as subdirectory structure, which is neither desired nor the previous behaviour.

How can I fix that and regenerate the classes in the same directory structure as before, while keeping the same namespace settings??

Thanks a lot!

[mikaelcom]

Indeed, you're right!

It was a personal decision and I considered that setting the namespace would mean that the files should be located at the corresponding directory structure. This was not the 3.x behaviour.

But you're right, namespace can be defined as you want without matching the directory structure using composer.

To match your desired behaviour, it would require a new option to disable the namespace-structured directory destination.

Do you agree that by default, the directory structure must match the namespace?

[mwolff-fn]

Hi Mikaël,

thanks for the quick reply 🙂

I agree that for new users the current behaviour is probably more intuitive. Having a flag to change back to the old behaviour would be great :-)

[mwolff-fn]

To elaborate why, in our particular situation the use case is that we got a package that contains domain and service classes that abstract away the Soap service from the consuming apps.
We keep the generated proxy classes in a separate directory from the hand-written sources, so we can safely delete and regenerate the whole directory when the WSDL changes, and so the QA tools and code coverage won't run for the generated classes.
We have more than one Soap service to cater to, so we keep them in separate root folders, like:

• proxies
  • soap
    • serviceA
    • serviceB
    • serviceC
      ...and since the share the same namespace, this now would translate to unnecessarily deep directory structures, like:
• proxies
  • soap
    • serviceA
      • My
        • Package
          • Namespace
            • Enum
            • Struct
            • Service
    • serviceB
      • My
        • Package
          • Namespace
            • Enum
            • Struct
            • Service
              ...and so on...

So I'd really like this to be configurable to avoid such structures.

[mikaelcom]

To be read #262 (comment)