pcplantdb

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

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.

Otherwise we are just hacking and kludging and winging it, not designing.

That would be a class one permaculture error, would it not?

So to keep the medium from eating the message, how about some serious 
observation and assessment here before we start implementing any more?

A little protracted and thoughtful observation instead of thoughtless 
and protracted labor?

I'm not a raging fan of formal documentation either, but given the 
relentless onslaught of wishlisting and feature-creeping and spin-offing 
and kitchen-sinking I keep seeing here, if we don't nail down an 
achievable "phase 1" in reasonably excruciating detail RSN we'll have 
little chance of ever completing it (maybe never even starting it...a 
constantly moving target is harder to hit...).

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.
  Yada yada....

>         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...

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.
  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...

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.

John S.

--

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