Have just completed a small static Web browser application. It is a bi-directional data capture application. In my case it is a stock order system. It works like this. You fill out a single page order form (which is an HTML form with external CSS files and external Javascript files) and email it as an attachment to the wholesaler. The wholesaler opens the attachment and prints it off. They wander around their warehouse ticking off the stock items as they are picked. When they are finished, they tick off the items on the HTML form, add any notes about the order (perhaps not all the stock is available and some of it has been placed on back order), regenerate the HTML form as text, which they cut and paste back into the email as a reply. When the email reply is received, the recipient copies and pastes the email body back into an HTML file on their desktop and views the revised form. This process can be repeated as many times as necessary until the stock order is complete.
What have I found out?
1. Javascript is so popular it's easy to find a solution to just about anything with a quick search on the Internet. Due to the nature of the language the explanations and solutions are very straight forward and easy to understand.
2. Using CSS for layout can be tricky. Content boxes don't always do what you would expect. I found myself using them on a trial and error basis most of the time. After a while I began coding most things in pixel sizes and using id selectors for everything. In Fox-Toolkit, text never exceeds it's content box boundary, but with CSS, sometimes it did.
3. Having a separate external CSS file for printing was fantastic. In every other software development environment I've used, with the exception of Microsoft Access, printing has always been a major problem. With CSS all I had to do was create a new style sheet and make everything invisible except for the stock table. It was done and dusted in 30 minutes.
4. The DOM (document object model) is another great feature of Web browsers and Javascript. It allowed me to easily create a dynamic table where new rows could be added and removed at run-time.
5. JSON too proved to be huge time saver, serialising and deserialising my Javascript data storage array with a couple of functions. In Classmaker, I had to write and debug my own lightweight tokenised string data structure (which by the way has been a wonderful thing - lightweight tokenised strings for data transport rock), which incidentally is very similar to JSON. With JSON it was all done for me. As argued by the proponents of JSON, XML is just too markup heavy for decent data transport performance.
6. My application has relied heavily on include files. The core HTML file is as small as I could make it. All the HTML markup code is located in an external Javascript file. With just 15 lines and 760 bytes in size, it is easy for core HTML file to be copied backwards and forwards as text in the email body. All the include files which are doing the heavy lifting are located on a Web server. Without include files the HTML file would have been too large to copy around as text.
After reading this you might be asking why? Why not create a spreadsheet and email that backwards and forwards? I didn't choose the spreadsheet route for three reasons:
1. I wanted the end users to have no software dependencies to worry about. By using a Web browser that is avoided. The only hiccup would be users who do not have Javascript enabled on their browser. To be frank, they would be a rare breed these days.
2. Printing was very important to me. I needed to be certain that printing out to hard copy would be painless for users.
3. I wanted the stock table rows to be created dynamically at run-time, with no opportunity for data to be loaded into unexpected places.
No comments:
Post a Comment