pcplantdb

[Chad Knepp <pyg@galatea.org>]

Richard Morris writes:
 > Chad Knepp wrote:
 > 
 > > Doing better, I think I have every major bug re: Zope ironed out with
 > > a fully function BTree based ObjectManager like product and functional
 > > HGObjects.  No [breakable] promises on a real release yet, but I can
 > > almost smell it.
 > > 
 > > This is the magical line that made my head hurt figuring out:
 > > manage_addProduct=App.FactoryDispatcher.ProductDispatcher()
 > > 
 > Well found. Its always these magic line which make things tricky.
 > 
 > > I knew OFS.ObjectManger had something that HG didn't but it's 691
 > > lines long and it took me a while to figure it was this one line.
 > > 
 > > Someone asked what 'HG' was.  HG is the internal name of the actual
 > > product, which stands for Holy Guacamole, which was the subject line
 > > of the Stephanies email to the list when she found out we got the
 > > grant.  It's funny, laugh!  Anyway, python is really truly named after
 > > Monty Python so we obviously fit in here.
 > > 
 > A slight concern about using HG throughout the code base.
 > I supose its a bit of an in joke and we will need to explain it to 
 > everyone who comes along. The danger is that five years done the line we 
 > may be cursing the HG tag. We should at least explain the HG tag 
 > somewhere high up in the documentation.

Sure thing.

 > I've had a quick browse through the code base Chad uploaded,
 > seems like theres a lot of work there.
 > 
 > Not sure how to get it running at home, any pointers?

If you unzip/untar it into $ZOPEINSTANCE/Products/ and then restart
Zope you should be able to add HG elements from the ZMI.  As I said
before, it is not very usable.  In fact that release was pre
manage_AddProduct which was preventing me from adding HG objects to
HG... ack!

 > Cultivars seems to be missing from the names bit. These are quite 
 > important in the pfaf db as there are lots of different apple cultivars 
 > some of which have different growing requirments.
 > 
 > There is a design decision here, should cultivars be a plant in their 
 > own right (i.e. an instance of class Plant) or as in the pfaf db
 > as a set of properties depending on a particular plant.

Implementation wise, I've been thinking that the root plant object
would actually only be a unique set of identifiers such as botanical
name.  Everything else would be a subobject that held this root as
it's parent.  This would allow the cleanest sort of localization
implementation I could think of, where localized info is just an
additional subobject and queries can select the object for localized
info if it exists.  Additionally this would allow the possibility to
annotate/comment on any element/subobject.  As a data structure this
will end up looking like a non-binary tree.  Cultivars would be a
subobject of a root plant object that had cultivar specific info.

 > I'd feel easier if the Botanical Names and Common names each had their 
 > own classes. I think this could be useful in the long term when we might 
 >   want to expand the types of name allowed, (say if we want to add a 
 > language for a common name, or if we have a rose specalist who's 
 > interested in forma). These also advantages if the accepted name and the 
 >    synonyms shared the same type.

This will probably be the case, common names being a subobject of the
plant root.  One thing I need to know from the group is what
constitutes a unique plant root object.  I think the line between what
is a cultivar or very minor subspecies is perhaps a little fuzzy.  One
thing we could do is have subobjects be children of multiple plant
root objects where the information was sufficiently similar.  Anyway,
my question is what combination of nomenclature should we use to
identify a unique plant in the context of what will be the most useful
division to our users.

 > We may also end up with a very heavy weight plant class with all the 
 > properties in it (hence harder to modify). Splitting the plant class 
 > into a main container class which have a number of smaller classes 
 > making up the whole could make for an easier object hiearachy.

I think we are on the same page here...

-- 
Chad Knepp
perl -e 'print pack"H*","7079674067616c617465612e6f72670a"'