>Now, these "global" functions would know all the types, and would be
able to call the appropriate *_impl functions for them. For
serialization to work, we need to store the type name in every
structure, per Carl's suggestion. For deserialization to work, we would
need to check the type name (xsi:Type) in the node.
>So, in terms of code, this would be, as suggested:
>struct adbType
>{
>axis2_char_t property_Type[64];
>}
Actually it is Dimuthu's idea, but it was my fault to suggest a 64 item
array. It should really be
struct adbType
{
axis2_char_t *property_Type;
}
And in the _create:
_type->property_Type = (axis2_char_t *)AXIS2_MALLOC(env->allocator,
sizeof(axis2_char_t) * axutil_strlen("<type name>");
strcpy(_type->property_Type, "<type name>");
In my project there is already a type name that is 50 characters long so
I would not be comfortable having any limit on type name in a code
generator.
>>So, the global serialization function could be:
axiom_node_t* AXIS2_CALL
adb_serialize(
adbType_t* _element,
const axutil_env_t *env, axiom_node_t *parent,
axiom_element_t *parent_element, int parent_tag_closed, axutil_hash_t
*namespaces, int *next_ns_index) {
if (strcmp(struct->property_Type, "adb_A") == 0) {
return adb_A_serialize_impl((adb_A_t *)_element,
env, parent, parent_element, parent_tag_closed,
namespaces, next_ns_index);
}
if (strcmp(struct->property_Type, "adb_A1") == 0) {
return adb_A1_serialize_impl((adb_A1_t *)_element,
env, parent, parent_element, parent_tag_closed,
namespaces, next_ns_index);
}
...
}
In the example above, I don't understand the adbType_t* used for the
_element parameter. Also, where is struct-> defined? Dimuthu's
suggestion of having a char pointer as the first element of the struct
for each sub-type allows a pointer to any sub-type object to be cast to
char *.
It seems better to use void * for the element parameter of the global
adb_serialize function. A modified version of your global serialization
function:
axiom_node_t* AXIS2_CALL
adb_serialize(
void *_element,
const axutil_env_t *env, axiom_node_t *parent,
axiom_element_t *parent_element, int parent_tag_closed, axutil_hash_t
*namespaces, int *next_ns_index) {
if (strcmp((char *)_element, "adb_A") == 0) {
return adb_A_serialize_impl((adb_A_t *)_element,
env, parent, parent_element, parent_tag_closed,
namespaces, next_ns_index);
}
if (strcmp((char *)_element, "adb_A1") == 0) {
return adb_A1_serialize_impl((adb_A1_t *)_element,
env, parent, parent_element, parent_tag_closed,
namespaces, next_ns_index);
}
...
}
>Neither of these would assure that you could only instance objects of
the specific type hierarchy you're expecting, however. Where would this
get done, and does it matter if it isn't?
You're right about the lack of parent hierarchy enforcement. You could
always add parent type information too, maybe using ';' so separate the
type names in the property_Type element of sub-type structures. I
believe Dimuthu said that the code generation engine provides parent
type information at the sub-type level.
In other words:
Adb_A1_create(..)
{
..
Strcpy(_adb_A1->property_Type, "adb_A1;adb_A"); // or
"adb_A1;adb_A;adb_parent_of_A" etc.
..
}
Then take the first token parsed out of this list when doing stricmp of
type information during serialization / deserialization.
The question then becomes is it worth this extra effort to implement
these checks? I don't believe it is, since the resulting XML document
should be validated by the server anyway.
Thoughts?
Carl
_____
"Ce message est confidentiel, a l'usage exclusif du destinataire
ci-dessus et son contenu ne represente en aucun cas un engagement de la
part de AXA, sauf en cas de stipulation expresse et par ecrit de la part
de AXA. Toute publication, utilisation ou diffusion, meme partielle,
doit etre autorisee prealablement. Si vous n'etes pas destinataire de ce
message, merci d'en avertir immediatement l'expediteur."
"This e-mail message is confidential, for the exclusive use of the
addressee and its contents shall not constitute a commitment by AXA,
except as otherwise specifically provided in writing by AXA. Any
unauthorized disclosure, use or dissemination, either whole or partial,
is prohibited. If you are not the intended recipient of the message,
please notify the sender immediately."
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
