prasannatsm / cropplanning Goto Github PK

Cell editors are not implemented in the table view although there are
constraints on the values entered into the detail view. We should define
numerous cell/textbox editors and assign them to each column or textbox
accordingly.

Eg: DateEditor could handle numerous date formats and format them all to a
standard which could stay in the db.

Eg: TextAutoCompleteFromDBColumnEditor or some such that could take a
column name and a DataModel, or a property type, and retrieve all of those
values from the database. The values would be used to populate the
autocomplete function.

Related to 
<a href="http://code.google.com/p/cropplanning/issues/detail?id=14">
issue 14</a>;

Allow users to display a crop plan in a calendar view based upon the dates
in the plan.

Perhaps a slight fork of issue 20, but we should enforce a system where
modules have the following high level methods:

 * constructor/load() - load module and do any initial work that doesn't
require any outside dependencies
 * init() - finish any initial work that DOES require external dependencies
(on crop plans, say, or databases)
 * reinit() - _maybe_, this would push through any changes in settings and
such, perhaps reload w/ a new datamodel
 * shutdown() - close connections, save settings, save state, etc

The rudiments of this are in place already in the basic API data structures
and interfaces, but modules will need to be retrofitted and the driver
module (CropPlanning) and ModuleManager will need some minor reworking to
make it work.

From comment 4 in issue 14:

We might as well add (in very small text) the date (and possibly time) when
the list was generated.

Or would this not be useful?

Right clicking on the "New" and "Duplicate" buttons should present a menu
allowing the user to access special functions for creating new entries:

   * "New"
    * "... planting of same crop"
    * "... planting of same variety"
        * "... crop in CropDB"
    * "... variety of selected crop in CropDB"
   * "Duplicate"
    * "... +1 week"
    * "... +2 weeks"
    * "... +1 month"
    * "... +2 months"
    * "... -1 week"

*Explanations*

"... planting of same crop" simply creates a new planting w/ the crop name
already filled in w/ the value of the selected entries crop name

"... planting of same variety" does the same except w/ crop and variety
names; ALTHOUGH, this is more or less just a "duplicate"

"... crop in CropDB" creates a new entry in the CropDB w/ all of the
information from the selected row; variety name should be left blank;
grey-out if crop already exists

"... variety of selected crop" same as above except fills in variety name;
grey out if variety already exists

The duplicate menu items are fairly self explanatory.  The program will
have to shift all dates which the user has entered (the .isValid() or
isConcrete() methods should check this).

Plantings should belong to "planting groups" which could be collapsed in
the plan.  Example: a plan might have numerous entries for "tomatoes", each
a different variety or something, but they would all be treated as a single
planting in effect.

Right clicking on the "Save Changes" Button in Detail View (both CropDB and
Crop Plans) should give the user the option "Save Changes As New Record
(Leave Current Entry Alone)"

As of mid-Jan 2008, the user cannot select which columns to display in the
tables.

User should be able to right click and select columns for display. This
list will have to be sent back to the datamodel (for caching?) for use when
submitting "abbreviated" queries.

Filtering should work for mulitple words: "melon plastic" should filter for
records with "melon" and "plastic".

Date filtering: May should filter for all records w/ dates in May.

From comment 2 in issue 14:

TODO lists should include a summary line at the bottom of each list.  It
should display totals for: flats, rowfeet, beds, etc

This is already supported by the data model, so it's just a matter of
adding it to the lists.

As of mid-Jan 2008, users can select which columns to sort and which order
to sort them simply by clicking on the column headers. The headers do not
display which column is being sorted, though.

Column headers should be given custom renderers which change color when a
column is sorted and should display an arrow indicating the sort order.

In order for the program to be useful for seed ordering, we will have to
track the following data:

 * amount needed per foot (or per 100'; in oz or grams)
 * sources of variety (ie catalogs)
 * item # and page (per source or catalog)
 * longevity of seed viability (order every year, 5 yr, 10 yr, etc...)
 * others??

These would tracked in the CropDB and users wanting to use the seed order
functions would have to use the CropDB.

In lieu of a proper in-program catalog aggregation and seed ordering
feature, we could then generate a "Seed Ordering Worksheet" from a
particular crop plan.  These worksheets might include the following data:

 * crop
 * variety
 * total plantings
 * total beds
 * total rowfeet
 * total flats
 * seed/foot (if appl.)
 * total seed needed (if appl.)
 * source/sources
 * cat # and page
 * planted last year?
 * have left over seed?
 * amt adjusted for leftover seed
 * notes?
 * how much ordered last year
 * how much is left from last year
 * did we reorder last year

 The user could then use this information or print out (specifically, the
source, cat#/page and total seed needed) to make ordering seeds easier.

What should "Enter" key do in Detail view?  Save record or just advance to
next field?  Resolve this question and then make it so.

The program already contains code to support autocompletion of some text
boxes (see the crop name in the CropPlans list view). This support should
be extended to all text boxes in the detail view that will have free-form
text entry.

Examples: Crop Name, Var. Name, Keywords, Groups, Family Name, etc.

This will improve the user experience by easing the task of data entry. It
will also reduce the amount of inconsistent entries.

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


Please use labels and text to provide additional information.

The window and the contained panes should behave more politely and "work
together".  They don't resize together or respect each others boundaries. 
Well, they should.

Currently, the list view and the detail view operate completely separately
and the code involves a lot of acrobatics to translate from CPS Objects
(Crops, Plantings, etc) to the db view.

We should rewrite all of the db calls so that they only return CPS Objects,
or lists thereof.  Then we can use something like Glazed Lists
(http://publicobject.com/glazedlists/) to handle the display of the data. 
When an object is clicked upon, it's just thrown over the detail view as
is, no more db queries.

Concern:
given the speed of HSQL, turning all of those entries into objects might
actually be slower than just bouncing queries off the db.

Closely related to Issue 48, we could add capabilities to handle more
germination stats (temps, bottom heat, moisture, days until ..., etc). 
This could give more precise instructions at seeding time.

Associate "timelines" of operations with crops in the database.  These
would be lists of operations, approx time to complete each operation and an
approximate time/date/week after planting for when they would happen.

This data could then be used for other reporting tasks, such as calendar
view (issue 13), todo lists (issue 14) and labor budgets.

User should be able to generate summaries of crop plans which can be
exported to PDF for printing.  These could include:

total/summary of crops and/or varieties by bed/rowfeet/yield

General statistics:
number of flats used
number of plantings which are DS or TP

Two improvements:

1) add a context menu to select which statistics to display
2) when multiple records are selected in the list, then the statistics
string should be updated just for those records

By default, text filters are ANDed and apply to all filterable fields.

We should add the following features:

1. NOT and OR keywords

2. literal string matching via double quotes (lower priority)

3. targeted field matching via search term prefixes.  This is the real
cherry on top.  We could recognize the following prefixes (or any leading
substring of them) to limit specific terms to specific fields:
    crop: Crop Name
    variety: Variety Name
    plant: Planting Date
    transplant: TP Date
    harvest: Harvest Date
    flat: Flat Size
    field or location: Field or Location
    group: Groups
    notes: Notes
    otherreq: Other Requirements
    etc...

Create a wizard that a user could pull up that would step them through this
or last years plan (or any plan, if fact) and have them evaluate it
planting by planting or crop by crop in order to update it for next year.

They should be able to say:
 * this planting was perfect
 * need more or less of this
 * need this more or less frequently
 * plant or care for this differently
 * "this crop doesn't exist in CropDB, create?"

This should also happen for crops in the CropDB:
 * this crop was planted perfectly
 * change spacing, times, maturity, etc, etc

Add a data field to track the germination percentage of a particular
variety.  This would be different than the "fudge factor" as currently
implemented.  As noted by StriderSnowbear (Jim), if you assume that the
fudge factor is tied to germination percentage, then the calculation is wrong:

---
A note on the fudge factor calculation.  If you want to actually calculate
the germination percentage accurately you will have to switch to the proper
mathematical formula.  The one you are using is not correct.  Your
automatic fudge factor is 20% in the settings menu, but the number of
transplants that the user is told to start actually is calculated as a 83%
germination vice the 80% germination indicated by the use of the 20 factor.
 This mistake is also present in the Market Farm Forms by Rosenweig, so
don't feel bad.  

Example:
you need 1000 transplants 
Germination % is 80%

Your formula is the following:
P * (1+G/100) = X
where P is the number of seeds to plant
G is the fudge factor in integer value vice in %germination
X is the number of transplants

Your result:  (1000) * 1.2 = 1200 seeds to start to get 1000 plants

but the actual number of plants you will get is this 1200 * (.80) = 960
transplants (you are short 40 transplants) as your formula calculates an
83% germination vice the 80% desired.  The effect of this error gets very
large as one heads toward 10's of thousands of transplants and/or the
germination percentage is a low number (say 75% vice 95%).

The correct formula is the following:

X = P/G
where X is the number of seeds to plant
P is the number of transplants needed
G is the germination percentage in decimal form

X = (1000)/(.80)  
   = 1250 seeds to start

 * select one row: enable all buttons & display selected entry
 * select multiple rows: change "Planting" to "plantings", disable
"duplicate" and "delete" (unless, of course, those functions can handle
multiple records), and display a common info query for those rows
 * when selection is canceled, or just no selection:
   (ie, data is updated and selected row no longer
   valid), blank the detail display and disable the 
   save/discard buttons
 * when no entries, "New" button should still be enabled
 * if only one row is returned from a filter, that row should be selected.

These rules should be reapplied when the data is updated and the table is
redisplayed: if all selected entries are still in the table, then make sure
they're still selected.  If all entries are not in the table, then make
sure that NONE of them are selected.

The software is heavily english.  We need to internationalize it, first and
foremost, and then begin providing translations.  Top translation
priorities: Spanish, Somali and Hmong.

Control or Right clicking on the "Duplicate" button should present a popup
menu allowing the user to select from the following options:

1. Duplicate
2. Dupe & shift 1 week
3. Dupe & shift 2 weeks
4. Dupe & shift 1 month

Etc. 

Currently (mid-Jan 2008) the table displayed in the master view is quite
crude. The crude column names should be replaced with more readable
equivalents.

We should use the Java Excel API at http://jexcelapi.sourceforge.net/ to
export to (and possibly import from) .xls format.  This would probably give
users warm fuzzies about being able to keep using their data even if the
program itself doesn't meet their needs.

New users will be COMPLETELY confused by the startup experience.  There
should be a "wizard" or something to step them through a couple of things:

1. location of data files
2. location of output files
3. create a new crop plan to work with

We should also provide some sort of info about how to create plantings
and/or crops.

This is a critical issue and will affect anyone who downloads the software.
 It's way, WAY confusing.

The database should store metadata about the last "known" version of the
HSQLDB module. (ie, which version was last used to access/modify the db) 
When a discrepancy is found (eg, the module is upgraded/updated), the
module should be able to "upgrade" the db to match the current
specification.  This should be incremental.

ie
  v0.0.8 ==> v0.0.9: "ALTER TABLE <cropplan> ADD COLUMN ..."
  v0.0.9 ==> v0.1.0: "ALTER TABLE crops_varieties ALTER COLUMN ... RENAME ...

and so on.  Then, if say a users upgrades from v0.0.8 to v0.1.0, all
statements in between the two would be executed sequentially and would, in
theory, bring everything up to parity.

We will need to produce a module or script that will lead the user through
the step by step process of creating crop plans.

Generally, the program grabs global settings (all settings, in fact) as it
needs them.  This is fine in most cases, but not for others.  The HSQLDB
module, for instance, grabs the data output directory at startup and never
checks it again.  If the user wants to change the location they keep their
data, they have to make the change and restart the program.  This is
somewhat counterintuitive.

PROPOSED FIX:
Define a settingsUpdated() method in one of the module classes and
implement it each of the modules.  For most of them, it would be empty.  We
could then call the settingsUpdated() method when the settings dialog is
closed.

Provide a way for the program to give the user feedback regarding the
feasibility of a planting.

Examples:

 * planting or transplanting date is before last frost date
 * harvest date is after first frost date
 * number of beds planned exceeds space available

This is a fairly simple enhancement which would allow users to limit the
display of data in the detail view.

In summary, a list of "basic" data would be maintained. A radio button or
combobox would be added to the detail view allowing the user to select
basic or advanced. In basic view, only those basic data would be displayed.
In advanced, all data would be displayed.

Basic data include: crop name, var name, maturity days, planting date,
harvest date and possibly some others.

Allow users to create weekly/daily/etc todo lists based on the dates and
records of a particular crop plan.

Certain elements of the UI should be displayed differently if a planting is
direct seeded or transplanted.  Currently, it's kind of confusing when
direct seeded plantings have many blank fields, even though that's what's
"supposed" to happen.

Users should be able to select which columns they would like to be included
in the todo lists.

The project needs to support multiple fields. This would entail creation of
a simple "field" schema and database table, plus related queries.

This would then have to be integrated into the rest of the software. At
present (mid Jan 2008), this would be simple since planting locations
aren't really used much anyway.

As an example of this integration, we would need to provide a new tab where
users can edit field information. Then we would have to link the "location"
of a planting to a predefined field. Calculations based on the length of
beds or rows for that planting would then be based upon the row/bed length
defined for that field.

This is low priority, easy task suitable for new or novice developers
looking for an easy way to get involved in the project. Some methods have
javadoc already, most do not. We are trying to keep all new methods
documented, but this sometimes doesn't happen.

Currently, columns are only sorted individually.  We should be able to sort
on multiple columns.  These could be added to the mix by holding CONTROL
and clicking on a column header.  A naked click would reset things back to
single column sort.

Add 3-4 fields into which the user can enter their own custom information.
 Perhaps they could even customize how they are labeled in-program.

Maturity adjustments are supported by the UI and the db, but they are
currently not used in any calculations.  They should be used when
estimating the planting/transplanting/harvest date.

We need to provide the user with the option of importing a "default" data
set.  I see that we could provide them with a few options, all of which
would just be a list of crops, not varieties.  One would be just a stripped
down list of crops, perhaps with other nonspecific info.  Another would be
to import info from "Johnnys" or "Harris" or such.  John Jeavons, French
Intensive, perhaps?

Other sources?

The program should include a simple "about" and/or "credits" dialog.  This
could on the menubar by itself, or under the "File" menu, which shouldn't
really be named "File" anyway.

It should include:

* program name
* current version
* project URL
* project email address
* list of sponsors, w/ links
* list of contributors

What steps will reproduce the problem?
1. Launch CropPlanning.app, then select output directory and click "Done"
to start program
2.
3.

What is the expected output? What do you see instead?
Window comes up that says: "Cannont launch Java application - Uncaught
exception in main method: java.lang.NullPointerException" and the only
option is to "Quit".

What version of the product are you using? On what operating system?
On a mac running OSX 10.4.11

Please provide any additional information below.
It is possible that my java environment is hosed in some way or another,
but I don't believe so.

_justin

The current module system is rudimentary and error prone.  We need to
augment this system to support:

1. Version checking
2. Module dependencies (w/ versions)
3. Provides/requires capabilities

ie: Module TODOLists; requires DataModel, HSQLDB v1.3; provides export:PDF,
planting-lists

Calculated figures should automatically recalculate when the users changes
other entries -- BEFORE the user "saves" the changes.

General idea of fix:

1) add change listeners to all affected boxes
2) upon change, the changed value will be set in the var
"displayedPlanting" and that object will be used to reset the display
3) special pains must be taken to ensure that the "changed" status of that
property is maintained, however.  Currently, all "changed" properties are
reset when displaying a record because of the use of the .setInitialText()
methods.

The list view should highlight entries in red when they fail a sanity check.