On 05/26/10 07:37 AM, Dave Miner wrote:
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(...)
Or, DC could register MyObjectDCVariant, and AI could register
MyObjectAIVariant with the cache prior to importing the manifest?
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
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
