Hi Dermot,
On Thu, 2 Dec 2010, Dermot McCluskey wrote:
Having Kwargs be a sub-class of DataObject is actually
ideal and was the way I had it implemented in one of
the earlier versions.
The problem that that poses is then the Kwargs DataObject
ends up in the DOC. This leads to the install_engine
not being able to validate those kwargs since they are a
DataObject and no longer a dictionary as required by the
engine's register_checkpoint() API.
I'm not sure I follow this completely, so please correct me if I've
got this wrong:
Would it not be possible to have Kwargs as a regular DataObject
sub-class, but also have an extra method in this class, called eg to_dict()
which converts the current object to a dictionary - which does basically
what I think lines 227-234 currently do. Then, when you are calling
register_checkpoint(), instead of passing a Kwargs object for the kwargs
keyword param, you would pass in the dictionary returned by calling
Kwargs.to_dict()?
Or even more transparently, kwargs could be a Python property of the
Checkpoint class, which fetches its child(ren) of type Kwargs from the
DOC and calls the to_dict() method on the child(ren)? That way, the
call to the engine would still look something like:
register_checkpoint(... kwargs=checkpoint.kwargs ...)
If the current code you have works, then I suppose it's fine. My main
problem with it is that it might be difficult to maintain.
Yep, the code I have works. At this stage I'm loathe to changing
it yet again but I can certainly file an RFE to improve it after
the initial push. Would that be acceptable to you?
However, I would also have expected that you would be setting the
generates_xml_for_children
flag somewhere in the Checkpoint class, so that the DOC knows
not to try to process the sub-elements of Checkpoint itself, as it will
otherwise do.
So, I would suggest that at least you rename Kwargs.to_xml and from_xml
and
set self.generates_xml_for_children = True in Checkpoint.from_xml().
I can certainly set generates_xml_for_children, is that a public
attribute though?
Yes.
In my testing I don't see the DOC trying to generate xml for the
children, it may just be due to the fact that there aren't any
classes defined that can handle <kwargs>.
That makes sense. But it's definitely more efficient to tell the DOC
that it doesn't need to be checking for registered classes to handle the
children.
Okay, I'll set that attribute.
Thanks,
Alok
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
