moyarada / xsd-to-php Goto Github PK

In some of the generated classes, some member variables are generated as "$someNS:variableName".

To reproduce it, import the GML feature schema:
<xsd:import namespace="http://www.opengis.net/gml" schemaLocation="http://schemas.opengis.net/gml/2.1.2/feature.xsd" />

In the process of marshalling a PHP class instance to XML, PhpXml should:

• throw an exception if class attribute has incompatible data type (@var annotation)
• throw an exception if we have minOccurs = 1 and no value has been provided
• not include an element in xml if its related attribute is null and minOccurs = 0

Now only "urn:" are supported

See for reference: http://www.w3.org/2001/03/14-annotated-WSDL-examples.html

It was not tested yet with this tag

Hello, how to generate PHP classes from XSD?
can you help me ? Thank you

I was wondering if I can generate php classes (representing the messages) straight from a WSDL?

Implement a method, which return a PHP model as an array.
For example,

Will return an array

array(
    "adGroupId" => 0,
    "adType" => 'TextAd',
    //...
)

It should be possible to inject custom logger to the library, so its log output could be seen.

http://legkoxml.org/docs

There is a problem with a schema having no namespace

Xsd2PhpTest::testSimpleSchema1
Actual:
@var http://www.w3.org/2001/XMLSchema\string
Expected:
@var www\w3\org_2001\XMLSchema\string

Though, it's not normal that string is not recognized as a basic type

In the generated classes, some of the extends clauses are generated as "extends someNS:someClass", which is erroneous. However, some other classes are generated without such error (which is generated as "extends someNS\someClass").

To reproduce this, just import the GML feature schema:
<xsd:import namespace="http://www.opengis.net/gml" schemaLocation="http://schemas.opengis.net/gml/2.1.2/feature.xsd" />

It seems that including and importing remote schema isn't supported. Bunches of empty "importing message" are printed on screen, and nothing is generated.

So I've made some change to the PHP and XSL a bit. I seems working on my box. How should I upload them?

I've tried to use Zend_Soap_Autodiscovery, and it turned out that it doesn't support namespaces in the way it can be of any use by Apache CXF. After some research I've found nothing, so it would be great to have a method, which can generate WSDL for a service, which uses PHP models already generated by XSD compiler.

Example:
Given a class, which must be exposed as webservice:

class ExampleService
{
/**
  * Extract name from ContactPerson model
  * 
  * @param dk\nordsign\schema\ContactPerson\ContactPerson $contactPerson Contact person model
  * 
  * @return string
  */
  public function update(dk\nordsign\schema\ContactPerson\ContactPerson $contactPerson) {
     // use contactPerson as follows
     $name = $contactPerson->name;
     return $name;
  }
}

Example SOAP server would look like

$service = new ExampleService();
if(isset($_GET['wsdl'])) {
  $legkoWsdl = new xsd2php\Wsdl($service);
  $legkoWsdl->setLocation("http://localhost:10088/api/soap.php");
  $legkoWsdl->setSchemasPath("../../application/resources/xsd");
  echo $legkoWsdl->getWsdl(); 
} else {
  $soap = new Zend_Soap_Server("http://localhost:10088/api/test.wsdl");
  $soap->setObject($service);
  $soap->handle();    
}

Now class name is not shown fully, it can be figured out from @xmlNamespace attribute

Using HL7 XSD schema https://dl.dropboxusercontent.com/u/8709992/HL7.xsd, I found that elements with periods in their name attributes were converted into classes with periods in their names, which is illegal syntax based on the PHP standard. I recommend name attributes be processed and substituted with legal characters as this is probably a general issue, not restricted to periods.

I do not receive an error or warning when generating the PHP classes from the XSD file. Rather PHP throws an error when trying to load the files.

This library seems good, but unfortunately due to lack of documentation and minor hangups, I'm going to parse my XML files manually. Not to dissuade you from working on the tool. But I've found most people have a low threshold for incorporating these sorts of libraries and will quickly fall back to one-off hacks due to time constraints.

It was added as the second argument of the constructor.

Example:
// Show debug output
$this->tclass = new xsd2php\Xsd2Php("../resources/ContactCompany/ContactCompany.xsd", true);
// Clean run
$this->tclass = new xsd2php\Xsd2Php("../resources/ContactCompany/ContactCompany.xsd", true);

There should be a tool, which will validate generated WSDL file.

I tried to run this on the SAML2 spec ([http://docs.oasis-open.org/security/saml/v2.0/saml-2.0-os.zip]) but the code seems to produce a fatal error on an undefined variable in the XSL file and it goes into an infinite loop (using Gbs of memory) when encountering an import when a URL in the schemaLocation.
These problems are fixed in the fork.

After fixing this the SAML2 classes still have issues with the namespace and classdefinition.

Preliminary Zend_Soap didn't work with namespaces and objects received in service classes weren't equal to specified in WSDL.

There should be implemented a method, which returns a classmap for given service class.

For example,
$service = new services\ExampleService();
$legkoXml = new xsd2php\Wsdl($service);
$soap = new Zend_Soap_Server("http://localhost/api/soap.php?wsdl");
$soap->setObject($service);
$soap->setClassmap($legkoXml->getClassMap());
$soap->handle();

getClassMap() should return an associative array as follows:

array('SOAP Type' => 'PHP Class',
       'SOAP Type' => 'PHP Class',
        ....
      )

It's better to have one class, that's responsible for all operation, instead of three different classes.
For example,

$xtp = new Xtp();

// Compile XSD

$xtp->generateCode($xsdFile);

// Marshal XML

$xtp->marshal($model, $xmlFile);

// Unmarshal XML

$xtp->unmarshal($xml);

Error: Fatal error: Uncaught exception 'Zend_Soap_Wsdl_Exception' with message 'Cannot add a complex type dk\nordsign\schema\ContactPerson\IDType that is not an object or where class could not be found in 'DefaultComplexType' strategy.

Hi. I forked this repo and added a composer.json file (along with cleaning up the "require_once" lines and the namespaces) and ran the unit tests, but I'm getting a mismatch between the expected xml output in the tests and the generated ones. The difference is that the namespaces are now empty. If you look here, you can see the empty namespaces. I tried to debug this to figure out where I went wrong, but I couldn't figure it out. Can someone help me fix this so I can make a PR afterwards? My fork is here. Thanks

IMHO, mapping a simpleType restriction to a group of static members would help producing less error-prone code.

e.g. mapping

<xs:simpleType name="ActivityStatus">
    <xs:restriction base="xs:string">
        <xs:enumeration value="pending"/>
        <xs:enumeration value="in_progress"/>
                    ...
    </xs:restriction>
</xs:simpleType>

to

class ActivityStatus {
     public static $PENDING = "pending";
     public static $IN_PROGRESS = "in_progress";
     ....
}

would allow a safer usage of ActivityStatus values

    $myStatus = ActivityStatus::$PENDING;

This tool should expose all functionality of the LegkoXML.

Examples:

$ legko compile-schema -xsd schema.xsd -dest ./generated/classes
$ legko generate-wsdl -service path/to/Service.php -xsd-dir path/to/schema -dest ./generated/wsdl