[Pipet Devel] WidgetMain() and more...

Brad Chapman chapmanb at arches.uga.edu
Wed Jan 5 12:50:40 EST 2000

J.W. Bizzaro wrote:
>    class WidgetMain()
>The name may change, but it should be the same for all widgets.
Gotcha! Makes sense now that I've been looking in-depth at the code. We can
change the name when we try to fit the widgets into loci-core.

J.W. Bizzaro wrote:
>> Note that since this now does XML parsing, loci-file requires something
>> new. I used the SAX (simple API for XML) complient parser from the python
>> xml toolkit.
>The licenses are acceptable.  I'd like to keep the number of extra packages
>that the user needs to install to a minimum though.  Does SAX provide what
>straight xmllib cannot?

Well, I did some looking at the xmllib documentation (in the general python
library docs) and now I have a better idea of what XML tools are in the
python distribution and what extra stuff is in the xml toolkit. While it
seems like basically whatever parser you use is a matter of personal
preference, I see a couple of advantages for the SAX parser:

1. SAX is based on a generalized API, which gives it some extra modularity
over any other parser application. In addition, it might be likely that
programmers have had exprience with SAX in other languages, which might
make the Loci code easier to follow and maintain by others.

2. From a bioinformatics standpoint, the proposed biopython BLAST parser
has a SAX-like interface, so it makes learning SAX twice as worthwhile for
anyone who will be used the BLAST parser and coding on Loci (namely, me!)

In general, I think we really do need the extra stuff from the xml toolkit.
It provides a DOM implementation, which we will really need, and
architectural forms processors, in addition to SAX and some other parsers.
In addition, if we want to stick with xmllib, the xml toolkit has some kind
of C extension that supposedly makes it 5 times as fast. With all the XML
work that we will need to do, my vote is definately for keeping the xml
toolkit. Any thoughts?

>How long would it take to do this for a large filesystem? at a remote
>These are the reasons why I wanted to use a list.  If trees are (1) made fast
>enough and (2) aren't used for every container, they would be good to use.
>Can you give us some feedback about these issues?

Sure. Since the tree implementation works in the new filegui.py thingy,
everyone can check it out on different size directories to their heart's
content. While I think it is plenty fast for medium sized directories (with
5 or so levels) if we want to stick with a tree representation we
definately need some limitations. I accidentally started parsing my /usr
directory (with 5 MB worth of stuff) and needless to say, I had to go in
and kill that process! I think a good way to limit the parsing and also
keep a tree representation would be to have the tree created only a certain
number of levels deep. Then, the user could have an idea of the contents of
subdirectories, and if they need to go into one subdirectory whose contents
weren't listed, they could drag the subdirectory as a new loci and see it
that way.
	I think I could implement this without too many problems. How does
this sound to everyone? Any thoughts on the number of levels to go? Other
	BTW, I don't think that the tree representation will be good for
databases. My thought is that a listing of the different databases
available in a particular locus will be good enough for that. I think that
there will probably be too much info in a database to represent in a simple
	Thanks for your comments on this!


More information about the Pipet-Devel mailing list