Writing Scripts

Objectives and Requirements

Open-Platform Programming

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

Client-side scripting instigate change based to actions performed by the local host, the user, i.e. creating change based on mouse or keyboard actions. In terms of web page design, Javascript is the client-side scripting language that allows that design to be dynamic, i.e. change fluidly based on the users’ actions. To capture such actions, Javascript utilises what is known as events and event handlers. These are triggers which activate once the specific action they look out for is triggered. For example:

<button onclick=”someFunction();”>someButton</button>

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

Alot of the script development happened in prior weeks before the Scripting module began. Much of the documented work can be found on Blog 7, Blog 8 & 9, and Blog 13.

Image Carousel

Very early on, one of the main client-side scripts I embedded in my website was an image carousel. I had found a solution suggested by another user on the internet, unbeknownst to me at the time, the suggested solution used JQuery. I had come across this solution really early on and so I was not fully aware how to utilise JQuery. The longest time I was trying to find out how to actually make the code work. Javascript being the carefree language that it is, would not highlight the clear problem I had, which was I was not importing the JQuery library. Without this library, my code would not work and each image I wanted to use in the carousel would show cascaded down the webpage with not behavioural change at all. Eventually I came across the page on W3Schools that mentions how to install JQuery. From there I learned I had to import JQuery and instantly my carousel worked. I tweaked the fade-in and fade-out qualities, but otherwise I did very little else to make the code work.

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.

Ordering System

A lot of the documentation following the development of this is already covered in Task 2 – Development Blog, Blog 8 & 9 and Blog 13.

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.

However the Ordering System did become very sever-side in the end as my penultimate goal for the ordering system was being reached. I always envisioned the system would read current stock information from a text file or Excel sheet; doing so would allow the business owner to easily update order information without needing to know any coding whatsoever. The ordering system also had to send the client’s order both to the client as confirmation and the business so they are aware of the order requested. These operations cannot be done with client-side Javascript programming, it was necessary to use a server-side language like PHP, which I did.

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:

2016-09-25-1

Once I was happy with this look, I set about getting a simulated read of a file by hardcoding the entire orderable items list in an array, and have Javascript read this array and construct the orderable items list accordingly. I am used to doing read files in other languages, so I already had a good idea of how to achieve this. What did stumble me initially was how to assign ID tags, which I knew would be necessary to update each items Total Cost field, but also the Grand Total fields which were to come at the bottom of the orderable items list.

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.

2016-09-26

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:

1) Transporting variables from PHP to Javascript. There is no direct method for doing so. There were some work-arounds I learned of on forums, but the simplest one I chose to use was write a <div> container in a PHP block which Javascript could pull values from using an ID. When it came to reading the inventory file in PHP, I would echo the file’s entire string to the <div> container in the same PHP block. I later decided on a <pre> tag instead, given I wanted to preserve any formatting in the file being read.

2016-10-30-92) 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.

2016-11-03-1
How it should appear on clicking submit

2016-11-03
How it would appear

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:

2016-11-13 (1).png

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.

Final Touch

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:

2016-11-13.png
How the confirmation page looks. I later added a copy of the order on this page
20161113_095722~01.jpg
This is what was printed when the PRINT button is hit
2016-11-03 (5).png
How the client receives a copy of the order via email from the system

And finally

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.

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s