pcplantdb

["John Schinnerer" <john@eco-living.net>]

Aloha,

One more, will finish catching up tomorrow...

> Word smithing here, but I would rather leave out the plant specific
> part, or I can buy into the plant part if part of the growing is to
> accommodate things other than plants eventually.

Agreed - critters of various types at some point I would assume, and of course
flexibility for that which we do not yet realize we will want to have in
there...

> I'm starting to fuzz out on what the front end would actually be
> anymore.  I would be interested in hearing what you think the front
> end is going to do and what the back end going to do.  Part of the
> problem is that my head is getting a little full of ideas.

Front end has multiple possibilities.  Possible ends of a possible spectrum:
* Nice simple low-bandwidth completely web-standards HTML/forms functional
focus type of thing for basics/for development IO use?/for accessibility/etc.
* Complex interactive graph-based visual interface such as Stephanie would
like to see

...and much in between.

I would say the front end provides some way for people to both submit
information and search for information.  Complexity of either or both to
depend on particular front end.

Back end does all the 'heavy lifting' - storing, indexing, searching,
collating, relating, retrieving, and so on of whatever information we want to
put in or get out.

That's my 39,000 ft. view.

Thanks Chad for your more detailed coverage of my brief stab at an
explanation.  What he says, folks...it really is great stuff.  I myself am
just getting to the point where I've done enough with it to really appreciate
how slick it can be.  I could have done the same with an RDB/SQL/HTML-munge
combo...but I'm really glad I didn't.

> The OO model is actually a lot more than that because it also includes
> methods (and more).  For example you could also do things like format
> your output within the object.  One of the features of Eden is to
> return search results in a short summary form (like google) instead of
> just latin/common name.  If each plant object had a method to generate
> a summary of itself I could just iterate over the search results
> calling the summary method of each object to generate my page.
>
> class Plant:
>       def __init__(self):
>         self.LatinName="NULL"
>         self.CommonName="NULL"
>         ...
>
>       def Generate_XML_Summary(self, format_style="default"):
>         xml =  self.LatinName, self.CommonName
>         xml += ...
>         return xml
> ...
> Graph based mapping of information is a snap when you are dealing
> objects.  One can easily add a method to traverse a set of objects in
> an arbitrary fashion (like linked lists or other data structures in C)
>
> class GuildAblePlant (Plant):
>       """ Guild capable plant """
>       ...
>
>       def GraphOnClimate (self, length_of_list=25)
>         """ Traverse based on climate similarities.
>             Returns a list of plants in decreasing order of
>             similarity.
>         """
>
>         ...
>         return list_of_plants

> XML is just a consistent and generalized approach to markup language.
> In our situation I think it makes sense for things like this
> <temperature type="Celsius">17</temperature> and then allowing for
> user preference to specify output units such as 17C or 67F.

If user decides output units, could we just pick a standard for our data and
dispense with the type="celsius" part? (for example...)

>  > What I'm doing for modoration of reader comments to PFAF DB
>  > is that I get emailed a copy of every comment submitted.
>  > It should be quite easy to do have a accept/reject email response.

> That doesn't sound like it would scale well.

Thanks again, that expresses my concern more clearly - I said something about
"design carefully" without knowing exactly what for...scalability is
definitely one important consideration.

We could agree on a baseline set of verification references for the "factual"
data and consider Jim's community-peer review option for the "narrative" data.

nighty-night,
John S.

John Schinnerer - MA, Whole Systems Design
------------------------------------------
- Eco-Living -
Design & Technology Services
People - Place - Learning - Integration
john@eco-living.net
http://eco-living.net