The report was written piece-wise by the group members involved in each section. As a result writing style and tense vary. The contributor of each section is listed at the end of the section.
In my attempts to set up our server, I initially looked to OIT. Maddie registered a MySQL server through http://mysqlserver.princeton.edu and I set up a webspace on one of our university unix shares. The OIT knowledgebase noted that the Webscript environment supports PHP, Perl and Python for CGI calls. As these were the technologies we planned on basing our site around, I decided this was a sufficient environment. After lots of testing to connect to our MySQL server through Perl and Python scripts (none of us had ever done this before so I figured the failure was in my implementation and not the server), I repeatedly attempted to contact OIT for help. Their answers were strained and lacked any real solutions. Maddie and I eventually figured out that the Webscript does not support Perl or Python, only PHP. As this was not sufficient for our work, we started looking for a new host.
I ended up registering us a filespace and webspace on the CS department web servers with a CS MySQL account. The CS servers support all generic scripting languages, so apart from allocating one of our personal computers as a server, it was our best option. My biggest issue was figuring out a suitable method for securing our database connection for prying eyes. The server configuration requires all CGI files to be read/write permissible to all users. I couldn’t store it in clear-text in a CGI file for obvious reasons; however there is no available method for encryption that isn’t easily reversible simply by reading the file that decrypts the password, which would have to be publicly viewable for operation. Discussion with the CS Staff revealed that the only usable solution was to store the password in a readable file outside of the public_html directory. This protects it from outside eyes, but anyone within the CS domain could still read it. For the scope of the project, it’s suitable, and would be corrected if moved to its own server for deployment. (Dan)
Getting the database set up was only the beginning of our experience with incompatibility issues. At first, we attempted to get ourselves hosted on the LAMP server, but it soon became evident that the functionality on that server was extremely limited because we were limited to a GUI interface with phpMyAdmin. This is clearly counterintuitive to what we wanted, because we had scripts that would automatically connect to the database and alter tables, but this proved to be impossible with the MYSQL database located on the LAMP server.
Eventually, we switched to the MYSQL server in the CS department, publicdb. It was much easier here, because our scripts could easily access our tables and alter values without any trouble. The only minor glitch was the lack of the LOAD command which would populate the information in a table given the name of the local file. This was easily circumvented by using the SOURCE command if we were running an interactive session with mysql (where I was inputting the commands myself), and if we wanted a script to perform a bulkupload, we would simply input the contents of the loader file as a “query” to the database. (Maddie)
While it was easy enough for us to get our hands on a sample club list, we soon realized that club cooperation was going to be a major problem. Since one member of the group was a prior tech chair at Cloister, we were able to get a hold of the club’s current listserv, used to send emails out to the entire club. With two of the other clubs that are currently listed in our database, it took some time before we could get the files, as each club stores its member lists differently, and some were hesitant to hand over the lists because they didn’t understand why we needed them. Also, the fact that there is no standard for member list formats made it somewhat difficult to create a parser for the various types of lists we could be sent.
We also learned that it’s very difficult to get cooperation from the clubs, as many clubs are resistant to change, which isn’t surprising since meal exchanges are still documented on slips of paper. Also, some of the more selective clubs are completely against sharing any of their member information, and they even safeguard such basic information such as the prices of their meals. Clearly, the change to a digital system such as ours will take some amount of time, but we hope that as more people use our service and realize how convenient it is, word will spread and the meal exchange manager will become more powerful and useful with the increase of users. (Maddie)
My first major task was to incorporate the CAS login to our site. As with many things in this project it is a fairly simple process (only) in hindsight. All that is required is to redirect to the CAS login page with a tag on where to go after login. Then you must query a different CAS page to verify the login. In order to do this, I discovered the PHP library CURL. This library allowed me to call a web page url and capture the result, all without any redirection. Once I discovered this, verifying the login, handling the redirection, and setting the cookies was a snap.
One of the major tasks of the client side scripting was to transform the POST data from the user interface into function calls of the server side scripts. This should have been a simple process using PHP, but the CS server did not allow the php library “system” to run due to security permissions. Instead, I was again forced to use CURL and absolute addressing to call the server side scripts. I did my best to allow for code portability by calling the directory url from workingDirectory.php so that changing that one file would update all of the absolute addresses.
One of the major headaches that I had in the beginning of the project was a lack of code reuse. I had the database connection and some other pieces of code in every single file I was working on. In order to make a change I had to alter the same piece of code in a dozen different files. By the end of the project, I had much better modularity, so making these changes were much easier. Lesson learned. (David)
Perl
All CGI calls operate through Perl scripts. This development went smoothly and was the earliest completed portion of the site. I defined an interface of CGI calls whose scripts acted as gateways to the backend. They passed the variables to internal Perl subroutines and printed the returned data back to the browser. The subroutines were divided into a set of Perl files grouped by relevance to club users, member users, database connection handling, AJAX calls, and generic utilities. This highly organized method worked extremely well for development and the modular approach to database connection avoided lots of redundancy. The only issues came up when Perl Modules we wanted to use were unavailable. I attempted to do local installs of the modules we wanted in our CS filespace, but was unable to make these work. I eventually found workarounds using already available resources that handled these situations. In general I think the project has given me good exposure to Perl, a language I was interested in learning. (Dan)
The mailing routines were done through Bash and Perl scripts. As explained above in the Perl section, all modules for handling mailing were unavailable on the CS servers and I was unable to successfully install them ourselves. As a result, the mailing was handled in a Bash script that calls a Perl script to build the email content and then sends it using the Unix sendmail utility. This worked well, and allowed me to spoof the sender address such that emails appear to come from “DONOTREPLY@mealsaver.princeton.edu”, rather than a personal account. (Note: The mailing scripts are not scheduled in our implementation as we do not want to send junk data to all club members in our test database) (Dan)
The front end of the site was a new experience for me, having very little experience with web development. Most of the front end was PHP/HTML based, while we used Javascript and AJAX for dynamic features. As the project progressed, I became much more comfortable with the languages and their capabilities, which also lead to realizations of how I could have designed the front end better overall.
Looking back, much of the consternation I experienced on the front end was either in aesthetics (things being where I wanted them, transitions, outlines, spacing, etc.) and returning or dynamically updating output of forms onto the same page as the form. At the very end of the project as I was researching table sorting, I realized that a more liberal usage of JavaScript and AJAX libraries could have alleviated many of these issues. Libraries, such as jQuery, provided table sorting with only a few lines of code, and if I had searched for and used them earlier, it would have most likely eliminated many of the problems I ran into along the way. With more time, I would have liked to use more of the features in the jQuery library, which we found very late in the project.
Other surprises I ran into came in the form of CSS and HTML standardizations. It is amazing how much discrepancy can result on different browsers when they are interpreting the exact same code. Fortunately, we made the good decision early on to keep all of our style in one external style sheet, using inline style extremely sparingly. This allowed for easy diagnostics and efficient fixes. Along with CSS standardization issues and discrepancies, this project has cautioned me from using the less standard features of HTML. For example, I tried using iframes to return the value of a form, but they responded differently in Firefox, Internet Explorer, and Safari. Because of this, we eventually decided to use the simpler, more robust, method of a JavaScript function which updated the div.
Overall, the front end went according to plan as far as the milestones. Throughout the project, it was important to keep in mind that simplicity and ease of use were paramount to our projects success. More features or options on the front end didn’t necessarily translate into a better product for the user. As far as these factors are concerned, I’m very pleased with the product, as we were able to utilize intuitive interfaces for all of our interfaces.
In terms of the front end interfacing with the middle and back ends. Our system of distributed responsibility worked very well. As nearly the entire front end interfaces were between my files and David’s files, we communicated well about each new file and made sure they interfaced correctly. It was also important that we were often able to sit down together, if only for an hour or two, and work on coordinating some of the more complex interfaces, such as loading the balance tables and returning the properly formed strings or error messages. (Evan)