Fine with most responses, just one I wanted to follow up on:
This is largely being facilitated by the move towards DC and AI sharing the
same Schema, but if there are differences we are considering passing flags to
the to_xml(), and maybe from_xml() (but I think this should be less necessary)
to allow for differences e.g.:
DataObject.to_xml( manifest_type = MANIFEST_TYPE_AI )
I think that sort of approach has potential of pushing detailed
application-specific knowledge into leaf objects. That seems
problematic to me.
Hmm, maybe it could have some effect, but it still seems to me to be the
correct place to have the decision made since each object would best know
where it fits in the over all scheme of things.
The only other alternative I can think of is to allow everything to generate
XML as if it's going into the overall-schema, and then the DOC later run an
XSLT or simlar over the generated XML tree, to produce an AI or DC varient,
removing nodes or modifying them as appropriate...
I would think that it would be more correct for the objects to be
application-agnostic in general, with specific applications implementing
subclasses if needed. Why wouldn't that be the preferred solution?
Hmm, I suppose that it's not impossible to do things that way - the main
concern that I would have is that you would have to provide a factory
mechanism which would make the decision on which object is created when
creating the tree, and this would be varied depending on the application.
In other words, people would have to do something like :
if is_DC:
return MyObjectDcVariant(...)
elif is_AI:
return MyObjectAiVariant(...)
any time they want to vary the object created depending on the application
being run.
In the end I think that this would be more complex than an XSLT solution or
passing flags to the to_xml() implementation.
I'm still pretty negative on flags to to_xml(), as I think it makes
objects much too aware of the containing application and reduces
reusability, but the XSLT solution you outlined later on seems
reasonably clean, so I'd encourage exploring that approach further.
Dave
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
