In our prior article we introduced the business and functional requirements for our Resume Publishing application. Business requirements detail "what" the does and "why" someone uses the the application. In this installment, we discuss the internal requirements. That is, "how" the application performs it's functions.

Data Structure Summary
Per our business and functional requirements the resume document is divided logically into row and columns.

The resume document contains one to many rows.

Each row contains one to twelve columns.

Each column contains a content property and a width property.

Each row contains a location property. (I.E. it's line number within the resume document).

The relationship between a row and a column is referred to as a row_column (or cell).

Each row_column contains a location property (I.E. horizontal position of the column inside the row). Note! This also allows for a future enhancement where a column is defined once but displayed many times within the document.

Data Structure Details

Row

• "id" an integer which serves as a unique identifier (key) for the row.
• "location" an integer which defines the rows vertical position in the document.

Column

• "id" an integer which serves as a unique identifier (key) for the column.
• "content" either plain text or html markup.
• "cssClass" a CSS class assigned to this column's parent html div element. Default value is the Twitter Bootstrap front-end framework rule "span1". "span1" means the column takes up 1/12th of the row's width. span2 2/12th's of the row's width, etc, etc.

Row_Column

• AKA "cell"
• "id" an integer which serves as a unique identifier (key) for this row_column.
• "row_id" number which identifies the row.
• "column_id" number which identifies the column.
• "location" horizontal position of the column within the row.

Collection
We need a collection (list) for each of the above entities:

• rowList
• columnList
• grid (AKA row_column list)

Each collection must allow us to:

• Add a entity.
• Retrieve and entity by it's id (key).
• Allow us to iterate through the list and retrieve all the entities.

Display Attributes
As mentioned before, we are going use the Twitter Bootstrap front-end framework to produce our "responsive" layout.

Specifically, we are going to use the "Fluid Grid system" described here: http://twitter.github.io/bootstrap/scaffolding.html#fluidGridSystem. As mentioned above, each row is contains one to twelve columns. Twitter Bootstrap "span[n]" CSS class defines the column width. So "span1" is 1/12th the width of the row. "span12" would make the column's width 100% of the row's width. All rows contain the same width.

In addition, you can a second Twitter Bootstrap CSS class to indent a column. For examaple, "offset2" indents the column 2/12th's of the row. I would refer to the Twitter Bootstrap front-end framework official documentation for further details.

Data Rules and Validations
For the initial design and release we aren't going to implement any validations. However, we do have a couple rules worth noting.

• When a user deletes a column from a row, the application must check to see if there are any remaining columns. In other words the application must identify when a user has deleted all columns within in a row. If there are no columns remaining, the application must delete the row also.
• To help the user identify a row_column (cell), the application should supply a default content value.
• The application should display row and column locations during edit actions (add, update, delete, etc.)

Initial Implementation on GitHub
I've added our project to GitHub here:
https://github.com/lorinpa/resume-publisher.

I implemented just enough of our requirements to render a simple grid.

I added the html, css and JavaScript in branch dev-1.0 here:
https://github.com/lorinpa/resume-publisher/tree/dev-1.0.

We our next installments, we will implement the rest of our application's requirements.