Re-inventing the Wheel
One of the most difficult tasks a PHP programmer faces is “fixing” a site built by another developer. Since I’m not a graphic designer, I try and keep the graphic design (typically stored in a CSS file) and use the customer’s goals to sketch out a class diagram of what needs to be accomplished. Sometimes I can find some little “PHP Gems” in the original developer’s code that can be incorporated into a class method, but for the most part, it’s easier and faster to dump the whole thing and re-start using OOP principles and design patterns. Often, a client will tell me “they just want a little change,” but usually a little change (e.g., “Make it work with mobile”) can cause unwanted consequences in unstructured code. The result is that the site crashes with the “little change.”
Recently, I had been asked to re-do a registration and log-in module. This turned out to be an interesting project because it’s something that most business and organizational sites require. The original log-in was a patch-work of snippets of code found online, and while some of it was fine, it was a mess structurally. This led me to consider the two dumbest pieces of advice in PHP programming:
PHP Dumb Advice 101:
- If it ain’t broke, don’t fix it.
- Don’t re-invent the wheel.
The first piece of dumb advice is the same as saying “Don’t improve it.” There’s nothing wrong looking for ways to improve a program for any number of reasons. The flexibility in OOP is designed so that you can improve and change code to make it better—add functionality, improve speed, or make it transportable. So just remember that while a horse worked just fine for transportation, a car works a lot better. The second dumb advice about not-reinventing the wheel means “Don’t look for better techniques.” A busy programmer who has to get a job done, yesterday!, will use the same old wheel just because she doesn’t have time to reinvent it. However, if you look at the history of the wheel, it just kept getting reinvented. OOP is a new kind of wheel.
It was with this attitude that I set about to make a basic registration module. I used the following conditions:
- Everything had to be a PHP object except the external CSS file
- Uses a MySql database
- A security class is kept separate from a registration class
- Checks for unique user names
- Registration object is never used before passing through security object
Before getting into the program, test it (click Play) and download the code:
Everything An Object
Every time I see an HTML and PHP code mix, I cringe. Yes, it works fine, but if you’re going to use HTML and PHP together, why not create a PHP object that you can use as an object, control the visibility of the properties and methods, and use interactively? In previous posts on this blog, you’ve seen heredoc strings used to wrap HTML code and assign that string to a private variable. This is easy to do; just write and debug the HTML, copy it all and dump it into a heredoc wrapper. So to begin, take a look at the following PHP class:
< ?php //RegisterUI.php error_reporting(E_ALL | E_STRICT); ini_set("display_errors", 1); function __autoload($class_name) { include $class_name . '.php'; } class RegisterUI implements IUI { //Get the table name from constant in interface private $bletchley=IUI::BLETCHLEY; private $regUI; public function __construct() { //Use the Security object to encode table $sec=new Security(); $this->bletchley=$sec->doEncode($this->bletchley); $this->regUI=< <<REGISTER DOCTYPE html> <html> <head> <link rel="stylesheet" type="text/css" href="login.css"/> <meta charset="UTF-8"/> <title>Registrationtitle> head> <body> <h2>Registrationh2> <h5>Create a user name and password.<br /> Make ones that are easy to remember but unique. (Like you!) 30-character limit.h5> <form action="Client.php" method="post" target="feedback"> <input type="hidden" name="secreg" value=$this-/>bletchley> <input type="text" name="username" maxlength="30"/> Username: one word with no spaces<br /> <input type="text" name="password" maxlength="30"/> Password: one word with no spaces<p>p> <input type="submit" name ="register" value ="Register me!"/> form> <iframe name="feedback">Feedbackiframe> body> html> REGISTER; echo $this->regUI; } } $worker=new RegisterUI(); ?> |
What I’m calling the “heredoc wrapper” refers to the portion of the code where the entire HTML5 document is “wrapped” in a heredoc string. The wrapper begins with the heredoc operator (<<<) and identifier (ALL CAPS) and terminates with the heredoc identifier followed by a semi-colon at the very beginning of a new line. In the RegisterUI class, the wrapper can be seen in a variable assignment that begins with,
$this->regUI=<<
and ends with,
REGISTER;
You can look at more posts on heredoc strings HERE and HERE and in the PHP Manual.
The important feature of wrapping HTML inside PHP classes is that you can do certain things with them that would be difficult or impossible with raw HTML. For example, as part of the class but outside of the REGISTER heredoc string are the lines:
private $bletchley=IUI::BLETCHLEY;
$this->bletchley=$sec->doEncode($this->bletchley);
Then, in the HTML line in the REGISTER string in the hidden form element,
bletchley>
you again see the private variable $this->bletchley. When you run the program, take a look at the HTML source code. Figure 1 shows what you will see:
Figure 1: Only code is visible in HTML Source
PHP’s interface structures are interesting in that while you cannot have any concrete methods stored in them; you can have constants, which must have assigned values. By placing the name of the table in the interface (IUI), it can first be encoded in the PHP class and then assigned as a value to a hidden form. So, even if the form is revealed in looking at the HTML source, the table’s actual name is hidden. The RegisterUI class implements the IUI interface. The interface itself is simple:
< ?php interface IUI { //Store name of table const BLETCHLEY ="registered"; } ?> |
As far as the user is concerned, all that he sees is the UI and a feedback window that lets him know whether his username and password are accepted or whether he has to try a different user name. Figure 2 shows this simple user interface:
Figure 2: User interface
The user just needs to see what she needs to register. The bare minimum in this example can be expanded, but to get started, it’s best to begin with just what we need and nothing more.
Continue reading ‘OOP Registration-Login Part I: Secure & Verify’
Recent Comments