Find a way to document 'enumerations' imposed by some SimpeTypes

[goetas]

Find a way to document 'enumerations' imposed by some SimpeTypes.

A possible way can be:

/**
 * Set the code doc...
 * @param string $code ... Possible values: 'A', 'B', 'C'
 */
public function setCode($code){
}

or

/**
 * Set the code doc...
 * Possible values: 'A', 'B', 'C'
 * @param string $code ...
 */
public function setCode($code){
}

[goetas]

Related to https://github.com/goetas/xsd2php/issues/34

[rtek]

Id go with option 2 as the list can get very long. May I request that $code is validated against possible values as well?

[goetas]

@rtek I have in mind to generate Symfony validation xml rules and validate the object against these definitions.

[goetas]

The option 2 will be used just as suggestions

[rtek]

In the case of named xs:simpleType, you may want to keep the empty class that contains the constants. It's convenient to have them during development.

<xs:simpleType name="typeOfMeter">
        <xs:restriction base="xs:string">
            <xs:enumeration value="Coal"/>
            <xs:enumeration value="Oil"/>
    </xs:restriction>
</xs:simpleType>

class TypeOfMeter
{
    const COAL = 'Coal';
    const OIL = 'Oil';
}

In the case of anonymous xs:simpleType, I agree that documentation would be sufficient.

<xs:element name="unitOfMeasure">
    <xs:simpleType>
        <xs:restriction base="xs:string">
            <xs:enumeration value="ccf (hundred cubic feet)"/>
            <xs:enumeration value="cf (cubic feet)"/>
        </xs:restriction>
    </xs:simpleType>
</xs:element>

[goetas]

@rtek this will cause to have a lot of empty classes... (and useful just as code suggestion)

• OTA XML has around 15% of empty classes.
• www.irs.gov has around 1000/4000 of empty classes.

[RSully]

Right now it looks like these enums aren't being handled at all (other than getters/setters - I don't even see any suggestions in the docblocks). I do agree that having constants is very helpful - maybe a necessity.

[ramittal]

There were classes generated for Enums prior to closing the issue#33 and they seems to work well. Why was this regressed? Will it be possible to bring that back so that I do not have to hardcode the strings? I would really like to see the Enums being handled as first class objects so that I do not have to deal with string casings and spelling errors.

[goetas]

At the beginning there was enums... but after https://github.com/goetas/xsd2php/issues/34 i've removed them. later, with https://github.com/goetas/xsd2php/commit/21b6d0933221f065394872f7a17775ebefa2b6e8 i have simplified the generated classes (less extensions when extending a base type).

I would really like to see the Enums being handled as first class objects so that I do not have to deal with string casings and spelling errors.

But looking the issue form a different perspective, enums can be useful even for code suggestion. The drawback is that big XSDs will have a lot of classes... but I think that I should re-implement it somehow.

Unfortunately at the moment I'm changing home, town and country, so I can get into this most probably in mid-January.

This project is still in "dev" just because I do not have a clear idea of how to make things in the right way. Thanks to yours issues and contributions I'm trying to find the most convenient way to handle XSD serialization-deserialization (things already solved in Java on .NET... )

I have a dream :-) : implement a suite of tools that allows to consume/produce webservices i a "Mucrosoft Visual Studio" way... just one click to import a WSDL, and use it in a object oriented way. I want to forget all XML stuff that works behind the scene.

[rtek]

Have you considered making enum class generation optional via flag and also doing the doc-block route? Everyone gets covered that way.

[goetas]

The option for enum classes is a good idea!

Doc block route? What you mean?

[rtek]

I would also include the list of possible values in the generated comments / doc block too. That way people still have access via IDE if they disable generated enum classes.

[davispeixoto]

I think this project can be used as dependency

"myclabs/php-enum" : "1.3.2"

Also, generate support for IDE auto-completion would be simples as

use MyCLabs\Enum\Enum;

/**
 * @method static Action VIEW()
 * @method static Action EDIT()
 */
class Action extends Enum
{
    const VIEW = 'view';
    const EDIT = 'edit';
}

[RSully]

@davispeixoto not a fan of using a subclass like this personally - maybe if it were implemented as a trait

[demonkoryu]

+1 for enums. ATM enumerations are just discarded. :(

[demonkoryu]

I've hacked something together that is enough for me ATM:

rtsde/xsd2php@0468ebe22bc0e8f9ca47e7d004223b83a3d48022

I'll issue a PR when I've cleaned it up and there's interest.

[discordier]

Could you change the commit so that you don't use auto reformatting which changes the whole file but only commit changes in the relevant lines?

I can not determine what you have changed.

[apropos]

with XML as follow

<xsd:element name="Type">
    <xsd:simpleType>
        <xsd:restriction base="xsd:string">
            <xsd:enumeration value="ISBN"/>
            <xsd:enumeration value="UPC"/>
        </xsd:restriction>
    </xsd:simpleType>
</xsd:element>

is it possible to do something like following while removing invalid chars from method name?

public function withTypeISBN()
{
    $this->type = 'ISBN';
    return $this;
}
public function withTypeUPC()
{
    $this->type = 'UPC';
    return $this;
}

[zarubaj]

What do you say about https://github.com/consistence/consistence ?

[goetas]

How this lib should help?

[zarubaj]

It's like a library "myclabs/php-enum" by @davispeixoto . The advantage is JMS Serializer integration