[Dev] odd itemref problem

[John Anderson]

I've been running into these problems all the time. They usually occur 
under the following situations:

When a tree of blocks gets copied to the soup (where it's displayed) you 
forget to add a cloud for the missing attribute.

When I use the parcel xml copy to copy a tree of blocks and it fails to 
work because of a circular dependency bug in the parcel loader.

Repository copy historically has bugs setting None attributes as initial 
values -- don't know if they are all fixed.

They are hard to track down, but I'd start by looking at the repository 
before and after any copies in Morgen's web viewer.

John


Alec Flett wrote:

>
> I'm curious if anyone else has seen a strange problem where an 
> itemref= is resolved, but the corresponding attribute isn't attached 
> to the python object.. specifcally, I'm using a <Tree> widget for 
> ZaoBao, and I'm declaring an instance of the widget with a child node 
> <rootPath itemref="doc:osaf-rss-channel"/>. doc:osaf-rss-channel is an 
> <RSSChannel> which is fairly well defined in an appropriate parcel.xml 
> file.
>
> what's happening is that the Tree class is trying to get to 
> self.rootPath and I'm getting:
>
>   File 
> "c:\alecf\tip\chandler\parcels\osaf\framework\blocks\ControlBlocks.py", l
> ine 1071, in wxSynchronizeWidget
>     root = self.blockItem.rootPath
>   File "c:\alecf\tip\chandler\repository\item\Item.py", line 158, in 
> __getattr__
>     return self.getAttributeValue(name)
>   File "c:\alecf\tip\chandler\repository\item\Item.py", line 586, in 
> getAttribut
> eValue
>     raise NoValueForAttributeError, (self, name)
> repository.item.ItemError.NoValueForAttributeError: 
> //userdata/{elcV_1Kkx7peQ$00
> lehY5n} (Kind: <Kind: Tree cf2ddb00-6e52-11d9-b491-00054e47c157>) has 
> no value f
> or 'rootPath'
>
> What's interesting, is that according to the schema, rootPath should 
> be None if the value isn't declared in the Item instance. instead the 
> attribute itself doesn't exist on the Tree object.
>
> I get no errors on startup reading the parcel.xml and I've done some 
> tests to verify:
> 1) doc:osaf-rss-channel is being properly resolved - I tried changing 
> it to doc:osaf-rss-channelZZZ and it correctly gives me an error on 
> startup
> 2) the RSSChannel type is well defined - I again fiddled with the 
> attributes of the osaf-rss-channel declaration, and it also correctly 
> gives me an error on startup
> 3) the rootPath attribute is correct - if I leave it out of the XML 
> file, self.rootPath actually exists, with a value of None.
>
> Does this sound familiar? Is there a well known parcel loader bug that 
> causes certain itemRefs to resolve but not attach the attribute to the 
> python object?
>
> Alec
>
>------------------------------------------------------------------------
>
>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
>Open Source Applications Foundation "Dev" mailing list
>http://lists.osafoundation.org/mailman/listinfo/dev
>  
>