The XML to PHP generator is used to create Plain Old PHP Objects (POPO) out of sample XML files.
This component will:
Read a pair of custom XML documents of a specified ERP message (request and response)
Generate POPOs with a constructor which will initialize all members
Generate a message class which contains a reference to the request and response POPO
Generate a factory class for the generated message class
Generate all necessary configuration files which may be imported or copied into the projects configuration
Document: A single XML document for ERP communication. One document may be sent to the ERP and another document may be received from the ERP
POPO: Plain Old PHP Object (a PHP object without any / further logic in its methods).
For a concept from Java see http://www.javaleaks.org/open-source/php/plain-old-php-object.html )
For a documentation of how it used in the eZ Commerce and examples please see ERP - Plain Old PHP Objects.
For the automated generation of PHP classes, additional information in the XML are necessary. The XML can be extended with the following attributes:
Required for elements, which are defined in external XML files and provide standard elements.
If an element value is a complex type which is intended to be reused in several messages (e.g. a business party record) it must be defined in this attribute.
The names of the types SHOULD be prefix with either
For each type an XML file MUST be stored in the src folder which defines the reusable datatype which is named <elementName>.xml
No, but must be set for elements, that may occur more than once.
Contains a (space speparated) list of sub-element names, that would have maxOccurence="unbounded" in XSD. These elements must always be arrays in PHP classes/objects.
|ses_tree||no, but must be set for XML elements that should be serialized and deserialized without being defined by the generated PHP classes.||This is a space separated list of elements which are intended to contain arbitrary tree data. It is mainly used for the SesExtension field. Elements defined in this attribute are considered by serialization processes to contain any XML tree structure, which is directly converted into an PHP, accordingly.|
No, optional but recommended
For documentation purposes. For example to document possible value-formats of a field.
This value will be written in the PHP docHeader of the member. (Not implemented, yet)
Further ses_... attributes could be implemented in the future. For example a "
ses_maxlength", which could truncate the length of a field in the getter/setter, to limit a field to a certain size (e.g. 30 characters)
Workflow of the message generation:
Create request and response XML files. The XML content should be available in a concept documentation in form of example XML or at least as a common structured data description.
The file names MUST fit to the following scheme:
request|response.<messageName>.xml whereas the content of
<messageName> will be the base name for the generated files.
You MUST define one file for each: request AND response.
The files MUST contain well-formed XML code.
Extend the XML according to the format, which is described above, if necessary.
Upload the XML documents to the resources folder:
e.g. for standard messages:
e.g. for non standard messages
Start the generation (check for any error messages):
Standard schema for command line:
The target and source directories MUST exist.
The target path MUST contain a 'src' directory. All directories beneath 'src' are considered as namespaces according to PSR-0.
The target path SHOULD be a Symfony bundle because all created sub-directories, like
Resources, are intended to be used in a Symfony bundle.
--forceparameter will overwrite all existing files. Use this parameter with caution as it will also overwrite standard classes if used in the defined message.
The script will now generate all necessary files into the following directories. Depending of the type of the class, <targetDir> is the SilversolutionsEshopBundle (for ses standard classes) or the defined target directory (in our example
in this directory, the configuration is stored, that must be included into the symfony application in order to activate the generated message factory.
to include this you:
might either import this file into the respective yaml-file in the app/config directory (e.g. config.yml). Example:
or you copy paste the content of this file in the respective services.yml (or *.xml, but then you have to reformat), Example:
After creating messages via the MessageInquiryService, values of a document can be changes easily.
A simple code example, working with the example (Party) message:
The converter is implemented within the SilversolutionsEshopBundle (Command/GenerateMessagesCommand.php and Generator/XmlToPhpGenerator.php)
The target directory for standard elements / messages is the SilversolutionsEshopBundle and not configurable.
The generated PHP classes and configurations are not validated automatically. This SHOULD be done manually after the generation.