Parameter Entry Page Added

The parameter entry page is the lowest level of the structure.  This
page is used to create new parameters or fields that can then be
grouped together on the group build page.
Parameter Page Functioning

The Parameter creation page is now functioning.  The user can insert
and remove parameters to and from the database.  The user will next be
able to add these parameters to field groups that will be used as spec
groups for products.
Group Page - Semi Functioning Grid

The Group page is added.  It's not functional, but the dojo grid does
display the database content.  The checkboxes have proven difficult
thus far.
Group - Checkboxes functioning

The checkboxes now transfer the selected fields.  There is a second
grid that displays the fields that are currently checked in the
parameter grid.  There is no other db interaction yet.
Group Page updated

Groups page now has grid of groups in the db.  The user can select
fields from the fields grid, see which fields are selected in the
selection grid, give the group a name and commit it to the db and see
the group grid update to include their new group.  I also restricted
additions to only allow unique group names.  There also must be a name
provided and the user must select at least one field.  Next step is to
add another grid that displays the fields included in the selected
group.
Group/Product Pages

Group Page has added group removal functionality, the interface was
simplified a bit.  And another grid was added that displays the fields
of the currently selected group.
The product builder page was created.  it lists the available groups.
The user can select from the available groups to define a new product.
A second grid displays all the parameters that are selected from the
selected groups.  Soon to come, there will be a list of completed
products that will also have remove functionality.
Product Page: Product creation now added

New Products can officially be added to the db.  They are also listed
in a grid once they are added.  Next up: removal of products from the
db and grid.  And a grid that displays all the specs of the selected
product and allows the user to set values for each spec.
Specs are saved in each product with an initial value of 0.
Product Page functionality completed

The product page can now successfully take groups from the db to define
a product, name a product, commit the new product to the db, display
all products in the db, display the specs of a selected product, and
allows the user to set values to specs of a selected product.
Parameter Page makeover

The Parameter page got a nice makeover.  The buttons are now
successfully dynamically added to the grid with each parameter.  Each
row contains a delete button that removes the Parameter from the grid
and db.  There's also a get button for the value and unit of each
parameter in the grid.  The get buttons place text into the
"Definition" textbox to define a computed field.  The format of the
"definition" text is still undecided.  The definition text will then be
parsed and displayed in the "Output" textbox.
The "Remove" button was removed because it is now obsolete due to the
delete buttons in the grid.
The "Insert" button was updated to be labeled more specifically and to
clear the text fields if a submission is successful.  The db
interaction was also updated to include the value and unit fields and
the uniqueness requirement of the parameter name is no longer applied
because uniqueness if implied by the combination of name, value, and
field.
Computed Fields update

The computed fields portion of the parameter page is somewhat working.
It's not the most user friendly experience, so would like to edit it
further.  It currently adds the element to the definition when the user
clicks the get button from the grid.  It separates elements by a
semi-colon.  If the user would like to add text between elements, they
add a semi-colon and click the "Append Text" button.  Then they are
free to add more elements to the definition.  Currently none of this
data gets saved to the database.  All files also received a credit and
use notice at the top of the documentation.
Computed Fields optimized

The computed fields definition and output now work as planned.  The
user can click the get buttons from the grid to place data into the
definition text field.  The user can also place custom data into the
definition text field.  Elements in the definition are separated by
semi-colons.
Here's an example:
{"field":"Port Nominal Voltage","property":"value"};{"field":"Port
Nominal Voltage","property":"unit"};", up to ";{"field":"Port Current
Max","property":"value"};{"field":"Port Current Max","property":"unit"}

The result is:
5V, up to 1.5A

(The numbers and units are collected and matched from the database).

The definition is still not yet added to the database.
Computed Fields commitable

The computed fields are now commitable to the db.  They are of a
different type than standard fields because they possess different
properties.  The entire definition string is stored along with a name.
A grid was added to the page to display the computed fields that exist
in the db.  It functions similarly to the Parameter grid: it shows a
row number, a name, the definition, a get button to copy the entire
definition to the definition input box, and a delete button to remove
the computed field from the database.

Some restrictions were added to the text fields to correctly require
certain fields depending on whether the checkbox to enter a computed
field is checked.

The submit new parameter button checks if the checkbox is checked and
this is how it determines what time of field to commit to the database.

The definition text fields were widened a bit to accomodate for their
lengthy content.

Next step, the view builder should now be more comprehendable to put
together.  The view builder will allow the user to create and customize
how spec reports are displayed.
Layout Overhaul 1.0

Overhaul on the layout.  Each Page is laid out to have three main
views.  The 'Create New' view, the 'List' view, and the 'Viewer' view.
The create new view is where a new objects members are chosen and/or
created.  The list view is where all the objects that exist are listed,
and the viewer view displays a selected objects members.
Each list view now possesses a delete button for each item in its grid.
Just Testing...

testing...
Features, features..

Parameter Builder:
Radio Buttons added and functioning,
Confirm button put in header,
Descriptions Simplified,
Groups Page:
Radion buttons added and functioning
Parameter grid displays value and units
Group Grid displays type
Group selection grid displays paramter values and units
Family Page:
Broken group selection grid because contents have changed on group
builder
Update soon.
Grid Details

Most grids now display types.  The database got an overhaul that
streamlines types.  The view grid on each page is also capable of
editing and storing changes.  The major bug at the moment is ensuring
no loss of computed field definitions when editing fields in the viewer
on the groups and product pages.
v1

Changed the parameter grids so they split vertically instead of
horizontally.  Made the computed input a little bit more short-hand.
Needs to be further optimized.  The groups now reference individual
paramter ids rather than parameter's data.  It stores an array of ids
instead of an array of JSON objects.  The intent is that when one of
those ids change, the group data will change.  I haven't been able to
get the data to display properly yet.

This is a new branch because we're going to try to go head on toward
asynchronous behavior.  The point is to have the grids really updating
live upon the data.  The first attempt will be to create sub-stores of
data and see if we can get the grid to update upon that sub-store on
the fly.  Once we get that implemented, we will implement a global
store of all the parameters to which the substores "subscribe."  So if
any of the global store's data is changed, all sub stores that are
subscribed to that data will update, and further, the associated grids
will update.
PI page Memory Store functional

The PI page grids are now functional with the memory store.  The
interactivity of the grids is much more dynamic and fluid.  Adding and
removing works well.

We started the idea backlog page for the Project Management project.
We need to correct the external javascript loading.
The parameter page is fully functional, the code in the parameter page has been cleaned up, the server and request handler files were cleaned up, i.e. removed old unused functions and old commented out code. Next step is to move the delete button from the grid to the header and have it delete the selected item. I will also implement the memory store for the group and product pages.
The parameter page delete button has been removed from the grid and placed above the grid.  The grid seems to work flawlessly. I also changed the way it interacts with the server.  When a new item is added to the db, the db returns the added item, I take the returned item and put it in the store. The remove function uses the Object id to remove a parameter now, which is better than referring to other fields.  The more I implement the store, the more code I seem to be able to remove.  It is getting close to where I can picture the grids modularly.  I could create a grid class as a wrapper of the dojo grid with my own functions.  Then I'll just use that class for each of my grids.  I didn't complete any of the tasks assigned yet today and they will surely take most if not all of tomorrow.