Moodle PHP Documentation 4.2
Moodle 4.2.8 (Build: 20240610) (2d41ac46f45)
|
Public Member Functions | |
decode ($xmlrpcVal, $options=array()) | |
Takes an xml-rpc Value in object instance and translates it into native PHP types, recursively. | |
decodeXml ($xmlVal, $options=array()) | |
Convert the xml representation of a method response, method request or single xml-rpc value into the appropriate object (a.k.a. | |
encode ($phpVal, $options=array()) | |
Takes native php types and encodes them into xml-rpc Value objects, recursively. | |
PhpXmlRpc\Encoder::decode | ( | $xmlrpcVal, | |
$options = array() ) |
Takes an xml-rpc Value in object instance and translates it into native PHP types, recursively.
Works with xml-rpc Request objects as input, too. Xmlrpc dateTime values will be converted to strings or DateTime objects depending on an $options parameter Supports i8 and NIL xml-rpc values without the need for specific options. Both xml-rpc arrays and structs are decoded into PHP arrays, with the exception described below: Given proper options parameter, can rebuild generic php object instances (provided those have been encoded to xml-rpc format using a corresponding option in php_xmlrpc_encode()). PLEASE NOTE that rebuilding php objects involves calling their constructor function. This means that the remote communication end can decide which php code will get executed on your server, leaving the door possibly open to 'php-injection' style of attacks (provided you have some classes defined on your server that might wreak havoc if instances are built outside an appropriate context). Make sure you trust the remote server/client before enabling this!
Value | Request | $xmlrpcVal | |
array | $options | accepted elements:
|
mixed |
Feature creep – add an option to allow converting xml-rpc dateTime values to unix timestamps (integers)
PhpXmlRpc\Encoder::decodeXml | ( | $xmlVal, | |
$options = array() ) |
Convert the xml representation of a method response, method request or single xml-rpc value into the appropriate object (a.k.a.
deserialize).
string | $xmlVal | |
array | $options | unused atm |
Value|Request|Response|false | false on error, or an instance of either Value, Request or Response |
is this a good name/class for this method? It does something quite different from 'decode' after all (returning objects vs returns plain php values)... In fact, it belongs rather to a Parser class
feature creep – we should allow an option to return php native types instead of PhpXmlRpc objects instances
feature creep – allow source charset to be passed in as an option, in case the xml misses its declaration
feature creep – allow expected type (val/req/resp) to be passed in as an option
PhpXmlRpc\Encoder::encode | ( | $phpVal, | |
$options = array() ) |
Takes native php types and encodes them into xml-rpc Value objects, recursively.
PHP strings, integers, floats and booleans have a straightforward encoding - note that integers will not be converted to xml-rpc <i8> elements, even if they exceed the 32-bit range. PHP arrays will be encoded to either xml-rpc structs or arrays, depending on whether they are hashes or plain 0..N integer indexed. PHP objects will be encoded into xml-rpc structs, except if they implement DateTimeInterface, in which case they will be encoded as dateTime values. PhpXmlRpc\Value objects will not be double-encoded - which makes it possible to pass in a pre-created base64 Value as part of a php array. If given a proper $options parameter, php object instances will be encoded into 'special' xml-rpc values, that can later be decoded into php object instances by calling php_xmlrpc_decode() with a corresponding option. PHP resource and NULL variables will be converted into uninitialized Value objects (which will lead to invalid xml-rpc when later serialized); to support encoding of the latter use the appropriate $options parameter.
mixed | $phpVal | the value to be converted into an xml-rpc value object |
array | $options | can include:
|
Value |
Feature creep – could support more types via optional type argument (string => datetime support has been added, ??? => base64 not yet). Also: allow auto-encoding of integers to i8 when too-big to fit into i4