Defined constants in index.php for various paths (e.g., includes, sections, etc.). Will employ the use of these across the application - this commit begins the process.
Added ability for admin to set the hopPelletFactor in the Preferences form.
Added sanity checking to the new field.
The bitterness library pulls the pelletFactor value from the preferences
table now.
Rearranged some of the code for readability and easier management.
Minor update to the interface.
Bitterness Calc
Significant rewrite to much of the code.
Modified interface to allow dynamic additions of hop entry fields.
Max number of hop entry fields is controlled by a constant at
the top of the file: $MAX_HOPS.
Moved all constants to the top.
Moved all JavaScript to bitterness.js since there's a lot more of
it now - the hop entry field stuff is all JS.
Modified the interface to make Garetz calculations optional.
Modifications to $pelletFactor. This is a constant at the top
right now but will soon be set in prefs.
Moved all IBU formulas into a separate library, bitterness.lib.php.
This will allow all IBU calculations to be handled in one file
instead of duplicating the code. The next step is to convert the
recipe/blog IBU code to start using it.
Updated all relevant files to link to the two calculators which
were modified/added.
The trunk folder is for all new features that are not yet ready for release. This folder will be for stabilizing work as it is built and creating new features.
The releases folder is used for release builds. The earliest available build is 2.3.x, and thus it will have the 2.3 folder. All maintenance and bug fixes go in this folder. No new features whatsoever are to be added in here, keeping those completely in the trunk. When the trunk is ready for the next version, it will have a new folder created for it (releases/2.4 for instance) to stabilizing for final release.
The tags folder is used for individual releases. When a release build is ready to go out for download, that release folder will be cloned into an appropriate tag folder. For example, the releases/2.3 folder will be cloned into tags/2.3.1 for that release, and after more work on bug fixes, it will be cloned to tags/2.3.2. Thus, these tag folders should never be modified for any reason. The tag exists purely as a snapshot of a certain point on the release path, and to modify a snapshot defeats the purpose. Any bug in a tagged release should be fixed in the appropriate release folder (such as releases/2.3 for a bug found in 2.3.1).
