Note, this articles is part of a series (here). In the previous installment we implemented data persistence. In this installment we complete our "must have" functions and thus, our initial release.
Logical Functions
These are the "must have" functions added for this installment.
- Publish HTML Document. The user can now publish their resume as an html document.
- Set Title (Web Browser Tab). The user can customize the document title text. This is the text that is displayed in the web browser tab control.
- Move Row. The user can move a document row to a new location. For example, move the top row to the bottom of the document.
Other Enhancements
These are changes which enhance current functionality.
- Toggle Edit Controls. The user can now turn the display of edit icons, on or off. The use can also turn the display of *cell borders, on or off. The user can preview the html document by hiding both edit icons and cell borders.
- Changed popup dialog position. The popup dialogues now display in top right hand corner of the web browser's view area. The pop up dialogues now overlay the top navigation bar. The only exception is the "cell edit dialog".
*Note. I added an option to display cell borders to help the resume author visualize the rows and columns. The cells borders are not displayed in the published document. The cell borders are only displayed during the edit process (when the user toggles cell border on).
Implementation
The issue I struggled with the most was "how to get the Twitter Bootstrap style sheets in to our published document".
Normally, the Twitter Bootstrap CSS rules are stored in an external file (or remote URL/a file located on a remote web server ). Your document then references the Bootstrap CSS rules via a <link> tag (placed in the document head section). Separating a large set of CSS rules in an external file/remote URL, is typical way to organize your document's data.
Our use case is a little different. Our goal is to produce a single html document the user can email to someone.
If the receiver of the email wants to view the resume while off-line, then a remote URL reference is not going to work. For example, someone gets on an elevator which blocks wireless signals (I.E. the person's phone is no longer connected to the internet). We want that person on the elevator to be able to view the resume with the intended layout. If our resume document references a remote URL located across the internet, our elevator rider's mobile phone won't be able to reference the CSS rules. The result is, our document is not rendered as intended (it's missing the CSS rules). Thus, a reference to an a remote URL is not going to work.
Referencing a local external file, also conflicts with our use case. Our resume author would have to email 2 files. The 2 files would need to always be in the same location (on the recipient's computer/mobile device). That scenario is way too unpredictable, it's just not practical. Therefore, referencing a second, local external file is not an option.
Thus, I decided to copy the Twitter Bootstrap CSS rules in to the published resume html document (I.E. in the html head section).
We still had one more issue. How do we get the Twitter Bootstrap CSS rules in to our published resume document. This is actually more of a user experience (UX) issue. We don't want the resume author, to have to locate, and then select, the proper CSS file. We want to limit the number of steps the resume author has to take.
The challenge requires a little explanation.
Our program can not simply open a file from the local file system. The user must locate and select a file, using the browser's file dialog. The program can not select the file. The user must select the file.
To complicate matters, our program can not set the default location of the file dialog. In other words, the file dialog could start anywhere on the file system.
Remember, our resume author at the end of the publishing process, is going to have to select a destination location and optionally a destination file name. If in addition, the resume author has to select the CSS files, that adds up to, way too many steps.
Thus, I applied the same solution to our main program listing. Instead of storing the Twitter Bootstrap CSS rules in an external file, I store them in the head section of our webapp.html file (our main program file listing). That eliminates any file dialog requirements to obtain the CSS rules. A document can access it's own contents.
Thus, our application's file organization is little unusual, but it works. Sometimes, just getting it to work is good enough :)
