pcplantdb

[Richard Morris <webmaster@pfaf.org>]

John Schinnerer wrote:

> Aloha,
>
> I repeat - we still don't have even a rudimentary formal spec and/or 
> requirements definition of any kind whatsoever nohow nowhere no siree.
>
> IMO this is most current task #1, #2 and #3 at the moment.

We seem to be converging on that.

> Can start by fleshing out some of the following with details.
> Helps to start with a functional description.
> Element A requires F and G and results in R, etc.
> Some off-cuff examples (in a real doc they'd all be multi-level outline 
> type format, bullet points, lists etc. etc.):
>
> >     User input. Getting the system running so that we can start
> >     accepting contributions. Can break this down into:
> >         Some form of login/account managment
>
> User interface will provide ability for user to creat an account.
>   Account creation requires a user name consisting of min. X max. Y 
> alphanumeric characters from sets [A-Z][a-z][0-9]
>   Account creation requires a user password consisting of min. X max. Y 
> alphanumeric character from sets [A-Z][a-z][0-9][!@#$%&*_-=+]
>   Account creation is accomplished using a GUI form with a field for 
> user name entry, a field for password entry, a field for password 
> verification and a form submission button.
>   Submission step one includes validating the user name, validating the 
> password, validating that password matches password confiramtion field.
>   Submission step two passes the valid user name and password to the 
> user account creation function/method/routine and verifies no errors 
> were raised in creation.

All good stuff. Might want to add some other user info, email address, 
web page.

> >         Working out database schema to allow user input.
>
> Working out database schema, period, at this point.
> DB schema not my table, someone with chops there please give an example...

The question here is that designing a DB which has user input may have 
very different structure to a straightforward readonly DB with no input.

For a simple DB it can be quite easy to design a structure
Each row might consist of:
PlantID | Latin Name | Height | Text description of edible use | ...
plus a few linked tables for one to many relationships.

When you bring users into the picture a number of issues occur
1) Can users just add data or do they have full edit facilities
2) If edit then we need some form of history management
    so that bad edits can be undone.
3) Is user input just a comment at the end or is it interweaved with the 
 different sections in the data. Chad's alluded to something along this 
line:

> The concept of being able to attach a comment to every/any 'object' is
> a concept I am quite into.  Defining object granularity as a sentence
> is a little smaller than I had in mind.  I was thinking more along the
> lines of a comment being the smallest object, but this could be
> multiple paragraphs.  

My take is that it would be posible to attach a comment to "info on 
edible uses", or attach a comment to "info on medicinal uses".

Hence user input may dictate a fundamentally different structure for
the DB. A typical table row might be
PlantID | CommentID | Latin Name | ....
and there might be multiple rows per plant!

I implemented a situation like this in the experimental DB at
        http://www.ibiblio.org/pfaf/pcplantdb/index.php
See the version notes for details on table structure.

> User input provides ability for registered user with adequate 
> permissions [there's another whole section, permission levels for 
> users...which depends on scheme for data vetting/validation, moderation, 
> 'hard' data vs. anecdotes and comments being nailed down] to add to 
> and/or modify information in the database.

Permisions keep simple: Read / Add / Edit / Admin (can do anything)

>   Adding data is done using a GUI form providing text fields, 
> drop-lists, selection lists, etc. as required for type of data to be added.
>     Selecting the "add data" function validates user permissions and 
> requests login/registration if user is anonymous.
>     If user is not authorized to add they are notified of this and no 
> action is taken.
>     If user is authorized to add, the intial "add data" 
> method/function/routine is called.
>       Next level of "add data" spec goes here...
>   Selecting the "edit data" function validates user permissions and 
> requests login/registration if user is anonymous.
>     If user is not authorized to edit they are notified of this and no 
> action is taken.
>     If user is authorized to edidt the intial "edit data" 
> method/function/routine is called.
>       Next level of "edit data" spec goes here...

All good stuff.

> There is a lot to do here.  Good news is that with a good spec/req. def. 
> the coding suddenly gets easier because "what to do" is laid out and 
> mostly it's down to "how to do it" rather than both at once.
>
> Of course this is a recursive/cyclical process and some "how to do it" 
> may lead us back to "what to do," that's fine.
> We have to start somewhere though, and that's with the alpha of "what to 
> do."
>
> >         Decide on what we do, and stick with it.
>
>
> VERY *VERY* MUCH AGREE.

A lot of what JohnS has written seems like it should go in a formal spec 
document.

We need to create a formal spec document. This could be:
a) wiki page
b) cvs file
c) something in the issue tracker?

Seems like we need to work out the spec for the formal spec (argh)

Rich