pcplantdb

[Chad Knepp <pyg@galatea.org>]

Richard Morris writes:
 > John Schinnerer wrote:
 > > Aloha,
 > > 
 > >>  > The permaculture.info project must
 > >>  > a) Hold data about a plant
 > >>  > b) Hold data about other objects/concepts not necessarily just a 
 > >> plant
 > >>  > c) Hold images, (and later other data formats like mp3's)
 > > 
 > > 
 > > c) is BLOBs, basically - up to you how to handle this on back end Chad.
 > > They're all just data files...would be good to have an attribute 
 > > identifying media/file type.  MIME standard would be one way.
 > > I strongly suggest *not* just hoping the file extension will identify it 
 > > well enough!  :-o
 > > I'll break that when I test it with a file attachment  from a Mac... ;-)
 > 
 > Yes they are BLOBS in terms of how they are actually stored.
 > At a higher level up the system we may want to embed the blob
 > in a suitable wrapper class
 > 
 > class Blob
 > 
 > class Image extends Blob
 >      int getWidth()
 >      int getHeight()
 >      String getAltText()
 > 
 > class JpegImage extends Image
 > 
 > At the end of the day what we need to do for the html page
 > is produce the html code
 > 
 > <img src="IMGURL" width="400" height="300" alt="Photo of a bannana">
 > 
 > where the IMGURL is whatever URL which will access the image.
 > The server will have to return the correct mime media type for IMGURL
 > in its HTTP response headers.
 > 
 > May well want to attach other various metadata to images and such like,
 > author, title, latin name of plants.

Or, if you remember my HGObject class example you could have a:

class HGImage(HGObject):
  def display(self, verbosity='terse', displayType='html')
    "Overriding display method in HGObject supperclass"
    ....
    return "<img src="IMGURL" width="400" height="300" alt="Photo of a 
bannana">"

 > Micro task: get system to return a page with an image in it.
 > 
 > >> 4) Moderated collaboration with different editing methods for
 > >>    different types.  I personally like a narrower approach than
 > >>    appendthing.php, like the ability to just edit the soil type.
 > >>    Moderation is the key to sorting the good information from the
 > >>    less good.  I don't really have a good idea on how to display
 > >>    differing information in a non-confusing way.  
 > > 
 > > 
 > > This goes back to one of our grantor's suggestions - two kinds of 
 > > moderation.
 > > One for relatively "hard" data, the basic stuff, where some limited 
 > > group of knowledgeable people make sure this sort of data is as correct 
 > > as it can be known to be.
 > > One for more "soft" types of data coming in from the larger community - 
 > > situational, locational stuff that may have more narrative/freeform 
 > > content than the more basic "hard" data. This could be (as Jim 
 > > suggested) a peer-group moderation system (as on eBay, etc.) where 
 > > people get rated as to the usefulness, validity, etc. of stuff they put 
 > > in.  Cream floats, bovine excrement sinks...
 > 
 > My tendancy is not to go overboard on moderation for stage 1.
 > Initially we will not have that many users so manual moderation
 > by us will do. I think we should focus of getting a product out the door.

I agree with you here, even though I think moderation essential to
having a largish scale system with many users, it's not really part of
the focus of this particular grant.  It's more of one of those things
on my personal todo list.

 > >>  > b) Allow multiple common names for plants (possibly with 
 > >> locilisation  > info describing where the name is used and which 
 > >> language it is in)
 > > 
 > > 
 > > Definitely useful...here in Hawai'i (and only here afaik) casaurina is 
 > > called "ironwood"...took me a looong time to find out what "ironwood" 
 > > was...lots of other things are called "ironwood" elsewhere in the 
 > > world...
 > > 
 > >> While this is a nice demostration of inheritance, hard-coding
 > >> information about off site links is a bit questionable.
 > > 
 > > Very questionable.  I will break it when I test and it will be a bug... 
 > > :-)
 > > This has to be something like...
 > >
 > 
 > Chad:
 > >> ...data not method, possibly as a attribute of the object in the form of
 > >> a list of urls.
 > 
 > Methods not data! First rule of OO design don't expose your
 > data, expose methods. Rather that
 >
 > class UDSALink
 >      public String url
 > 
 > have
 > 
 > class UDSALink
 >      private String url
 >      public String getURL() { return url; }
 >              // or something more complicated.
 > 
 > in the latter case its easier to change the method if needed, in the
 > first case we are tied forever to an internal representation of a url
 > as a String.

Yes and no.  This is more of a style issue because if you added a
method public Void setURL(String newUrl){url = newURL;} to USDALink
even though 'url' is private it is completely accessible via methods.
The difference is the means of access.  What you are describing is
what I learned in college as the correct way but this is not how it's
done in the real world very often.  Direct attribute access is fairly
common in python.  In fact, most builtin python classes have directly
accessible attributes.  If Guido does it then it must be ok right?
Part of the reason is that python has a very different concept of
namespace than C++.  I actually think Java is similar to Python
here...  

The most common sorts of access should of course be methods, not for
purposes of isolation, but so that subclasses can override these
methods in subtle ways without breaking the interface.  Because
off-site links related to an object would be a commonly used thing I
can envision methods like (pseudocode):

  method getUrls():
        return urls

  method addUrl(url):
        urls.append(url)

  method changeUrl(oldUrl, newUrl)
        ....
        if (changeWorked):
          return True
        else:
          return False

etc...

 > > I have plenty of examples of this on my own long-unmaintained resource 
 > > links pages.  Some of the gov't. sites are the worst!  Bureaucratic 
 > > shuffling, webmaster job security, I dunno...they tweak little bits of 
 > > the URL because some agency moved to some other sub-agency, and 
 > > everything is broken (again)...
 > 
 > Theres a nice way of handelling this on mathworld. Besides
 > each link is a little "fix broken link" button, so we can, to
 > some extent, let our users do the work for us. (or at least point out 
 > where the problems are).

Yup.

-- 
Chad Knepp
python -c 'import base64;print base64.decodestring("cHlnQGdhbGF0ZWEub3Jn")'