Objectives and Requirements
Wolandscat gives a pretty good explanation of why open platform come about and what its benefit it by applying it to the car industry. In the early days, every new car model to hit the streets was made entirely from stratch, a timely and costly process. The solution to this problem was to standardise key componants so they could be reused across different models, in other words, create a platform (a basis) for how these key componants such as engine or transmission should be interfaced (connected) with the overall system. This allowed parts to be made simulataneously, all under the assumption that these parts will be connected based on the conceived platform. In other words, you let everyone know how parts should interact and connect with the overall system, but as to how the specific parts themselves operate, these need not be disclosed.
Consider for example the iPhone, not all the parts have been made by Apple, in fact in the past it used to use LG displays. LG did not need to know how the iPhone worked to create these displays, rather they only needed the interface to be supplied, i.e. how the display will receive it’s input, to construct the part.
Open-platform programming is most often associated with APIs (Application Programming Interface), and it can be seen why. APIs provide the functions and methods programmers need in order to interface their created modules and create wholly unique programs. APIs are the platform underpinning the programs a user can make, and they are open, to be used by anyone but their inner workings may not necessarily be exposed but rather hidden and proprietary (not open source). It is thanks to these open-platform APIs that programmers do not have to waste endless hours creating programs from scratch, but can instead create programs relatively quickly in ever increasingly complexity by utilising the power of open platforms from which one can base their code on.
Client-Side Scripting and Dynamic Web Page Design
onclick is an event that listens out for the user clicking on the someButton, when this action occurs the event is fired and someFunction is run.
Outline of Security Restrictions on Servers
- Restrict Privileges
- Everyone should not be an administrator with complete access, the majority of users should have restricted privileges and restricted access to certain parts of the system.
- Prohibit Weak Password
- Ensure users have passwords that exceed a predetermined strength level.
- Restrict Unsecure Protocols
- Prefer a secure protocol such as HTTPS over HTTP to ensure data is not intercepted.
Server-Side v Client-Side Scripting
As mentioned earlier, client-side scripting is run on the local machine, i.e. the users’ machines. Server-side scripting on the otherhand is run on the server machine instead. Client-side scripting is also run after the webpage has loaded, whereas server-side scripting is run before a webpage has begun to load, in this regard server-side scripting is quite similar to how pre-processor commands work in C++.
Programming Documentation Standards
The purpose of programming documentation is to ensure that anybody looking at code or a program constructed by others can understand how it works and can be used. Programming documentation is meant to be written in plain English, and should explain how something works without getting into the nitty gritty of the processes involved. To ensure programming documentation is easily understand across developers, standards are necessary. There is no one standard for all languages, nor is there one standard for any one language itself, but there are generally accepted standards and there can even be locally created standards for an organisation to use itself. An example standard to follow for documenting functions could be as such:
What the function does [Adds two numbers]
What the function parameters are [A (integer), B (integer)]
What the function outputs [Returns sum of A and B]
Development of Scripts
Only just recently, I added audio to the index page, and this runs after carousel loads. I initially had problems trying to get this to work, until I realised I had to put the <audio> tag after the carousel <div>. HTML is sequentially loaded by nature, so by having the audio tag underneath the carousel <div> ensures the audio is not even touched on until the carousel <div> has been loaded and processed. The audio was a creative commons song acquired online that I edited down using Audacity. The audio does not quite loop perfectly with the carousel, an extra image in the carousel and some tweaking to the fades and delays could lead both elements to loop in tandem, but I felt it was such a minor improvement for the amount of work needed that I did not bother to do so.
This was my most favourite scripts to program and admittedly it is not wholly client-side scripting. In the beginning it was client-side scripting as it contained an editable textfield for each orderable item, and on changing the value in a textfield, the respective <pre> text field would produce the sum amount for that item by multipling the user’s inputted quantity amount and the pre-defined unit cost.
There were many stumbling blocks along the way but thankfully it all works beautifully now.
I always knew I would be reading in a file and so I first set out creating a prototype for how the order menu should be displayed and worked by hardcoding just a few lines. I toyed with the idea of having two windows, with one side having a list of orderable items, and a +/- button to change the quantity ordered and for any item that is ordered (quantity > 0) the item would be populated in the right window. I quickly realised this way would be needlessly complicated to pull off. Instead it would be far easier just to list the items in one window, have an editable quantity field for each item, and then have a non-editable field update with the total cost for ordered x number of that item whenever the user entered a quantity greater than 0. Hardcoding this design choice resulted in the following look:
Since I had no need to grab IDs outside the orderable items <div> I realised I could simply make the orderable item’s name the tag, and differeniate the quantity and cost fields relating to that item different by affixing either “-cost” or “-total” to the ID tag.
The above image shows just a simple test of two orderable items, once this worked I implemented the full list of orderable items. Later on I separated these items by category, and have the populateOrderMenu() function identify if it was processing an orderable item or a category tag (which did not require a cost field nor quantity field etc).
Later down the track I moved my entire project onto 000webhostapp to obtain server capability and finally implement some much needed server-side PHP scripting. Using PHP was necessary to be able to finally read a file, and it would later allow me to jump the user to a confirmation-of-order page, as well as email that order to the customer and the business. I have already discussed at length the development processed that occured when I started using XAMPP to simulate a server to test PHP, and the implementation of the file read features as well as the additional features added to the order page and confirmation page in Blog 12 and Blog 13.
Some key issues I ran into and how I solved them are:
2) The disappearing Confirmation Screen. This problem was the most irritating issue I ran into. For what appeared to be a random reason, the confirmation screen (which appears when the user submits an order and is presented with a confirmation of the amount, before requesting final submission), would work sometimes and sometimes would not.
I had some suspicions as to what was going on. I first suspected it was due to the transitionEnd event that I used to reveal the contents on the confirmation screen (the confirmation screen drops down from the top and once it is fully exposed, it reveals its contents). I learned that transitionEnd can be problematic depending on the browser, as each browser has its own native transitionEnd event type. For example, Firefox is mozTransitionEnd. Browsers, especially modern browsers, will likely support the standard transitionEnd event, but using the browser-specific types gives greater guarantee.
This did not fully correct the issue, so I thought perhaps the event was not firing at all. It was, but the IF conditional I had planted in the revealConfirmation() function (that reveals the confirmation screen’s contents) was not always proving to be true. The IF conditional was a failsafe to ensure that the contents would reveal only if the confirmation screen’s height was 100%. It would appear that due to the confirmation screen being nested inside another <div> it does not necessarily reach 100% in height. This seemed to fix the problem, however I later discovered the issue persisted with the web hosted version.
On my local server the confirmation screen was revealing itself perfectly fine, but the web version hosted by 000webhostapp was not. I thought perhaps it was an issue of the server, given it did have some latency problems with loading my images haphazardly on occassion, but later on I found out it could be an issue with caching. I first twigged it could be the cache when I discovered the confirmation-of-order email would fire multiple times on browser refresh. Trolling through the forums, I learned that if the browser loads from cache, it will not load a webpage from scratch (i.e. what is hardcoded in the HTML and CSS files). It was this that was causing issues with the confirmation screen.
The task then was to find out how to prevent the browser from loading from cache and I came across this solution on PHP’s website:
Both lines capture two supported ways of preventing browsers loading from cache. The first line tells the browser explicitly not to do so. This line is supported in earlier versions of HTML (or so I am led to believe), the second line indicates that the webpage expired in the past. Whenever a browser believes a webpage expired in the page, it does not load the content from its cache.
Implementing this, seemed to fully correct the problem of the confirmation screen hiding itself.
When the user confirms the order they submitted and has entered their details, they are taken to a confirmation page which would report if the order submission was a success or not, and provides the user an order number. The confirmation page also sent a copy of the order to both the client and the business. I later added the ability to print the confirmation page via a button click, and provided a copy of the order on the confirmation page as well:
To play with the webhosted version of the site, please visit here: MainStreet.
PLEASE NOTE: Emails are sent to my personal account on submitting an order. By all means do so, but please use the name TEST or something similar so I know it is an intentional test of the system.