Hi Phillip,
Hope you're weathering the weather :-) ... I'm trying to track down a
problem where an installParcel() is getting called twice, with different
values for the 'parcel' parameter (which means it creates twice as many
repository items, parented in two different places!).
The parcel is parcels/osaf/framework/attributeEditors. the __init__.py
in this directory imports (among other things) installParcel() from the
AttributeEditors.py file (also in this directory). If I put a breakpoint
on the installParcel() method in AttributeEditors.py, and launch
Chandler with --create, I see that it gets called twice, with different
'parcel's:
The first time, the 'parcel' parameter prints as: <Parcel (new):
attributeEditors e9260d9a-459a-11da-c3e3-0050f2e8b09c> (note the
lowercase "a" in "attributeEditors").
The second time, it prints as: <Parcel (new): AttributeEditors
e9260d9a-459a-11da-c3e2-0050f2e8b09c> (note the uppercase "A" in
"AttributeEditors").
I've tried to do figure out where the different import paths, but
haven't succeeded in learning anything. I did find three "problems" that
I thought might be related:
1. When called the first time, the installParcel call is happening as a
result of this line in
parcels/osaf/framework/blocks/detail/detailblocks.py[148]:
AttributeEditorMapping.update(parcel, typeName,
className=__name__ + '.' + className)
where "AttributeEditorMapping" was imported using the first line in the
file:
from Detail import *
Thinking that this sloppy importing might be the problem, I tried
changing this line to mention all the specific classes from Detail that
were actually needed (that is, "from Detail import (AppearsInAreaBlock,
AcceptShareButtonBlock, [etc])") but that didn't seem to help.
2. I found one place (osaf/framework/scripting.py[12]) that was
needlessly importing using the specific file instead of the parcel:
import osaf.framework.attributeEditors.AttributeEditors as
AttributeEditors
should be:
import osaf.framework.attributeEditors as AttributeEditors
but fixing that didn't help either.
3. ControlBlocks.py has a circular dependency on AttributeEditors (there
are widget classes defined in ControlBlocks.py referenced by the
attribute editor classes in AttributeEditors.py, and the attribute
editor picking mechanism in AttributeEditors.py is referenced by a
couple of the block classes in ControlBlocks.py). While it'd be nice to
refactor this problem away, I didn't try this.
Can you please give this a try and maybe shed light on how this might be
happening?
Thanks,
...Bryan
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
