> > I found that the 'annotations' I was allowing on XML elements was
somehow
> > clashing with the 'Pythonic' (delegating) 'XML merge' code. Don't ask me
> > why, but removing it allowed a major major metadata load speed-up.
Minutes
> > back to seconds.
>
> Wow, that's cool! But please help my oor little brain come back to
> coding after my vacation... what are these 'annotations' you are talking
> about?
Good question. In gump/utils/note.py we have Annotation (a simple
level/text) and Annotatable (contains a list of Annotations) and helper
methods like 'addError','addInfo','addWarn','addDebug'. Theoretically this
ought be a trivial & not too heavyweight way to 'log onto an object'.
I added this to the XML loading because I wanted to capture error/warning
conditions from that process, and store them 'in context' (on the XML object
they effected). The sort of errors are 'no such URL' (for HTTP download),
'badly formed XML', etc. Warnings include 'Gump doesn't understand <mkdir on
<ant', and such.
There is code to 'display' annotations, see :
http://brutus.apache.org:8080/gump/xml-forrest/index.html#Annotations
http://brutus.apache.org:8080/gump/notesLog.html
[and BTW I am looking forward to being able to colour errors as red and
warnings as yellow, some day.]
Anyway, I guess either adding this list per object is 'too much' (maybe) or
somehow the Pythonic object delegations (gnarly stuff) got kicked out of
it's sweet spot due to having an 'annotations' attribute (rather than none).
I lean towards the latter.
I'll add a JIRA entry to re-visit this issue, 'cos I do want those
errors/warnings.
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
