Closed staabm closed 8 years ago
I do indeed think that this is a case that falls outside what I want to do with the valueobject stuff. There is after all a pretty good way to deal with these with the elementMappers.
The issue I see is that if we keep on adding functionality that makes that stuff more complex, in the end we either reinvent XSLT or a different domain-specific language that describes parsing. We don't need that, because we can achieve it with PHP code.
I hate my use-cases :/
Wouldn't something like this just work:
$service->elementMap['{http://clxERP/businessparty}business-party'] = function($reader) {
return \Sabre\Xml\Deserializers\valueObject($reader, 'SomeClass', 'http://clxERP/businessparty_types');
});
Gets you 99% there, no? And that's mostly 'configuration'.
hmm this sounds like a good idea... need to check that, thx.
worked for me, thx.
atm we dont support schemas in which a element has a type from a different namespace, e.g.
problem is, that our valueObject deserializer atm asumes that the
xs:element
and itstype
are within the same package. As you can see here this is not necessarily the case.example message
In my use-case I want the
store_businessparty_request
and thebusiness_party
both be de-serialized using thevalueObject
facilities. In thebusiness_party
case my value-object doesnt pick up any values, because it only takes those which are part of the same namespaces as the element itself was defined.