|
Let me clear the air a bit more here. In the way we have implemented both ‘choice’
and ‘all’ constructs, we use C++ NULL value to check if some field
is optional in serialization. In other words, if a field is optional as per the
WSDL definition, and if the C++ class attribute is NULL, then we simply do not deserialize the value. However, this assumption seems to fail in
case of ‘nillable’ values. The current
implementation works with nillable values correctly for
‘all’ and ‘choice’ constructs as far as a given attribute
(I mean a data member) is not both nillable and
optional at the same time. (To my understanding, in practice, this is unlikely
to happen, but if it happens the implementation would fail) Let me give a practicle
example with the ‘all’ construct. In the test WSDL ComplexTypeAll.wsdl used for the
test NilValuesTest we have: <xsd:complexType
name="aRecord"> <xsd:all> <xsd:element
name="field1" type="xsd:string" nillable="true"/> <xsd:element
name="field2" type="xsd:string"
fixed="field2Value"/> <xsd:element
name="field3" type="xsd:string" nillable="false"/> </xsd:all> </xsd:complexType> Going by the ‘all’ construct
definition, since minOccursis not
mentioned, it is a must that all fields MUST appear in the aRecord
and out of those field1 could be NULL. However, if I change the definition to the
following we run into trouble: <xsd:complexType
name="aRecord"> <xsd:all> <xsd:element
name="field1" type="xsd:string" minOccurs=”0” nillable="true"/> <xsd:element
name="field2" type="xsd:string"
fixed="field2Value"/> <xsd:element
name="field3" type="xsd:string" nillable="false"/> </xsd:all> </xsd:complexType> Now, field1 is both optional and niallable. As per the current implementation, if field1 is
set to (C++) NULL, we would deem that it is optional and would not sterilize it
now. However, as the element is nillable, we could
have serialized the element as a null (empty) element, but the current
implementation does not do that. Is this a problem? Thanks, Samisa… -----Original Message----- Hi All, I implemented the support for
‘choice’ WSDL construct in Axis C++ . According to our
design, generated stub level classes serialize the choice elements in the
following way. int
Axis_Serialize_ChoiceComplexType(ChoiceComplexType* param,
IWrapperSoapSerializer* pSZ, bool bArray = false) {
if ( param == NULL )
{
/* TODO : may need to check nillable value - Now done*/
pSZ->serializeAsAttribute( "xsi:nil", 0, (void*)&(xsd_boolean_true),
XSD_BOOLEAN);
pSZ->serialize( ">", NULL);
return AXIS_SUCCESS;
}
/* first serialize attributes if any*/
pSZ->serialize( ">", 0);
/* then serialize elements if any*/
pSZ->serializeAsElement("NonChoiceIntValue",
Axis_URI_ChoiceComplexType, (void*)&(param->NonChoiceIntValue),
XSD_INT);
//…………………………………………………………………………………………………………………… //Following two
elements are choice elements // if the element
is not NULL it goes to deserializer if(param->IntValue)
{
pSZ->serializeAsElement("IntValue", Axis_URI_ChoiceComplexType,
(void*)(param->IntValue), XSD_INT);
}
else if(param->StringValue)
{
pSZ->serializeAsElement("StringValue", Axis_URI_ChoiceComplexType,
(void*)(param->StringValue), XSD_STRING);
}
//………………………………………………………………………………………………………………………. pSZ->serializeAsElement("NonChoiceStringValue",
Axis_URI_ChoiceComplexType, (void*)(param->NonChoiceStringValue),
XSD_STRING);
return AXIS_SUCCESS; } But if the choice element is a
nillable one and its value is set to NULL, then the above logic will fail. Any thoughts on this?? Regards, Marcus Dushshantha
Chandradasa Associate Software Engineer Virtusa (Pvt) Ltd. Mob: 0714867441 |
- RE: Handling Nillable elements which are wsdl choices Samisa Abeysinghe
- Re: Handling Nillable elements which are wsdl choic... Samisa Abeysinghe
- RE: Handling Nillable elements which are wsdl choic... Samisa Abeysinghe
