Security And Caffeine

Code’s towards the bottom if you can’t be buggered to read my ramblings.

The Challenge: Add new “pages” (page divs) during execution in a mobile app. This was part of a project using jQuery Mobile and PhoneGap, and the information that I wanted to display wouldn’t be available until the app ran and was subject to change. In this case, the app lists a number of companies, and each was supposed to have their own “page” within the app. Tap the company name, see the company info. Simple, right?

The Reason: The app I was working on had a basic layout that could be coded beforehand, but much of the data would be unknown until the app actually ran and pulled that data from a server. Since the various companies that the app listed could change at any time, this needed to be dynamic. While the approval time for apps on mobile devices is enough of a burden (up to three weeks or more), I had the additional hurdle that an update for every new company might degrade user confidence. Yes, updating your apps too frequently can erode confidence, because the users start wondering what, exactly, you’re screwing up so bad that you need to patch it every week or two.
Read full story

This is a much condensed version of the original post.

Usually, processing form data means getting either POST or GET data from a form, and trying to figure out, in code, what you have, and then do something with it.  This can be easy or complicated, depending on how much is being passed in.  Email address only? Easy.  Checkboxes, optional fields, and so on, all together?  Pain.  Often, a lot of form processing is done with stacks of “if” statements.  This sucks.  Here is a better way:

From now on, I want you to name all of your “real” form elements (ones that have data that could change, so not buttons) using the name you would have given then, plus an array name, that they will all share.

So,

<input type="text" name="username" id="username" />

becomes

<input type="text" name="formdata[username]" id="username" />

Why?  Instead of having one array ($_POST), you’ll now have two ($_POST and ‘formdata’, within $_POST).  Your buttons and other “static” form elements will still live in $_POST, but everything containing data that needs handling will be in the ‘formdata’ array, which you can access as $_POST[formdata].
Read full story

During the Spring Semester of 2007, I worked as the lead developer on the UAT Rogue Forums.  The project was designed and lead by Jordan Womack, a UAT Master’s Student.  Under him, the Rogue Forums was created as an alternative to UAT’s intranet forums; general opinion of the intranet forums was quite low.

We used and modified phpBB.  My portion of the project was to re-skin the bulletin board system, act as lead moderator, prevent non-UAT students from registering, and implement the post voting system.  phpBB version 3, RC5 was used and updated to subsequent release candidates.
Read full story