April, 2010

IDE / Netbeans / PHP / Programming — 3 Comments
29
Apr 10

Netbeans 6.9: My New Favourite Features

Netbeans 6.9 beta was recently released, here are some of the new features for the PHP editor that are pretty awesome.

The first one is recognizing overridden methods and classes. This feature is great because it allows for better auto completion, and lets you find things faster.

Not only does it recognize that I am extending the class, it recognizes that the function I am writing is overriding a function in the parent class, and provides hints as to what that function did (based on the comments that you *did* write right?).

After you hit enter (because you actually want to override that function, you get this (including a call to parent::functionName()):

There is a little green circular O icon beside your function because it is overriding a parent function (granted this would make more sense if I were using __construct rather than php4 syntax). Hovering over the O tells you which function you are overriding, and where it is. Clicking on that icon will take you to the actual declaration of that function:

You will notice that there is a different green O icon (a square one this time, with a small black arrow. Hovering over that will tell you that the function/class “Is Overridden”. Clicking on it will give you the locations that Netbeans found it to be overridden. Clicking on one of those will take you to the location that it is being overridden.

The second feature that is quite neat is the updated commit dialog.

The first thing you will notice (if you used previous versions of Netbeans) is that they added checkboxes beside the files, much more intuitive than the way it was before (a bunch of drop downs that you would miss if you didn’t know they were there).

You can also now right-click on the files you are committing and there is now an option to view the diff of the file you have selected. Selecting the Diff option will show you the familiar diff view:

The second tab (Textual) will let you create a patch file from your changes:

This new tab also shows up in the Diff view, and you can create patches from the diff between two files (not sure how useful that actually is when they are completely different files), or the changes you have made to a single file.

In addition to the old badges for modified files (blue icon on parent folders, blue text) and new files (blue icon on parent folders, green text), there is now an error badge (red icon on the file) which will show up when there are errors in a file.

There are lots of other new features including ini syntax colouring, more formatting options, go to css declaration, it will display the value of a constant you are using.

There are of course many other new features unrelated to what I do every day, you should go check it out for yourself.

Best Practices / PHP / Programming — 2 Comments
21
Apr 10

Exceptions Are Not For Flow Control

When I saw this post on Better Error Handling, while there is nothing horribly horribly wrong with it I couldn’t help thinking that he has gone past proper error handling. Exceptions are for exceptional cases, hence the name. They should not to be used for flow control, or for things that could occur normally like a user failing to login.

This is because almost all function calls are basically a question:

  • Did the user enter the correct information to login? Yes, No
  • Did the database query return data? Here is the data array, here is an empty array.
  • Is the data that the user entered valid? Yes, No.

Within these functions, you can pass an error to the next screen, view, wherever you are returning to because the function failed to produce a positive result.

Things that are exceptional cases would be something similar to the following. In these cases, you cannot continue because the assumptions made by your code were not fulfilled.

  • A malformed query on the database (MalformedDatabaseQueryException)
  • no connection to the database (DatabaseMissingException)
  • the database timed out (DatabaseWentAwayException)
  • A file is deleted while you are reading/writing it (FileWentAwayException)
  • trying to call a function that takes an integer by passing it a string, object or array (InvalidDataTypeException)

The problem with using exceptions for flow control is that you will inevitably end up with something like this if you want to handle each exception individually:

<?php
try{
	$user->login();
} catch(InvalidDataException $e){
	//handle invalid data exception
}catch(CouldNotLogInException $e){
	//handle could not login
}catch(DatabaseException $e){
	//handle database exception
}

Or something like this if you don’t want to check all possible errors:

 
<?php
try{
	$user->login();
} catch(Exception $e){
	//handle exception
}

The problem with the second one is that now you are treating all exceptions the same way regardless of their actual severity.

Or, if you are validating data:

try{
	validateUsername($_POST['username']);
} catch(Exception $e){
	//handle exception
}
 
try{
	validatePassword($_POST['password']);
} catch(Exception $e){
	//handle exception
}
 
try{
	validateDateOfBirth($_POST['birthday']);
} catch(Exception $e){
	//handle exception
}
 
try{
	validateTwitterAccount($_POST['twitter_account']);
} catch(Exception $e){
	//handle exception
}
//and so on...

Or if you are lazy:

try{
	validateUsername($_POST['username']);
	validatePassword($_POST['password']);
	validateDateOfBirth($_POST['birthday']);
	validateTwitterAccount($_POST['twitter_account']);
} catch(Exception $e){
	//handle exception
}

But then you can only show the user the first thing that failed. Which is not good from a usability perspective because they might have messed up everything after the username, and would then have to submit the form 4 times.

Instead you could do this:

/**
 * Show the fatal error page when an exception occurs
 * @var Exception $exception;
 */
function myExceptionHandler($exception){
	displayErrorPage($exception->getMessage());
}
set_exception_handler('myExceptionHandler');
 
$u = new user();
$u->username = $_POST['username'];
$u->password = $_POST['password'];
$u->birthday = $_POST['birthday'];
$u->twitter_account = $_POST['twitter_account'];
if($u->save()){
	//continue to the next page with a confirmation message
} else {
	//show the user the errors that occurred on the page they just came from
}

Which is a much nicer alternative.

Best Practices / PHP / Programming / Ruby / WTF — 7 Comments
14
Apr 10

PHP Functions, you’re doing it wrong…

Just a quick tip today. If your function looks something like this:

 
<?php
/**
 * A really long function definition
 * @param string $has
 * @param bool $a
 * @param int $lot
 * @param float $of
 * @param assoc_array $parameters
 * @param string $I
 * @param string $wonder
 * @param int $what
 * @param int $they
 * @param int $do 
 */
function myfunction(
	$has=null,
	$a=null,
	$lot=null,
	$of=null,
	$parameters=null,
	$I=null,
	$wonder=null,
	$what=null, 
	$they=null,
	$do=null
	){
	//do some magic
}
 
//this is how it would be called
myfunction(null, false, null, 1.2, array('one'=>1, 'two'=>2), 'I', null, 1, null, 3);

You are doing it wrong, if all of these parameters are really nullable and required for your function, and there is no way for you to split it up, then you _can_ refactor it like this:

 
<?php
/**
 * Quickly refactored to make it easier to use
 * @param array $array containing: (string)'has', (bool)'a', (int)'lot', (float)'of', (assoc_array)'parameters', (string)'I', (string)'wonder', (int)'what', (int)'they', (int)'do'
 */
function myFunction(array $array){
	//make sure we are only taking in parameters that we recognize...
	$has = isset($array['has'])? $array['has']:null;
	//array key exists because it is a fake boolean value... it has 3 possibilities
	$a = array_key_exists('a', $array)? $array['a']:null;
	$lot = isset($array['lot'])? $array['lot']:null;
	$of = isset($array['of'])? $array['of']:null;
	$parameters = isset($array['parameters'])? $array['parameters']:null;
	$I = isset($array['I'])? $array['I']:null;
	$wonder = isset($array['wonder'])? $array['hwonders']:null;
	$what = isset($array['what'])? $array['what']:null;
	$they = isset($array['they'])? $array['they']:null;
	$do = isset($array['do'])? $array['do']:null;
 
	//some magic
}
 
//it could also be written:
 
/**
 * Quickly refactored to make it easier to use
 * @param array $array containing: (string)'has', (bool)'a', (int)'lot', (float)'of', (assoc_array)'parameters', (string)'I', (string)'wonder', (int)'what', (int)'they', (int)'do'
 */
function myFunction(array $array){
	//make sure we are only taking in parameters that we recognize...
	$args = array('has', 'a', 'lot', 'of', 'parameters', 'I', 'wonder', 'what', 'they', 'do');
	foreach($args as $arg){
		$$arg = array_key_exists($arg, $array)? $array[$arg]:null;
	}
	//some magic
}
 
 
 
//this is how it would be called
//equivalent to:
//myfunction(null, false, null, 1.2, array('one'=>1, 'two'=>2), 'I', null, 1, null, 3);
myfunction(array('a'=> false, 'lot'=>1.2, 'parameters'=>array('one'=>1, 'two'=>2), 'I'=>'I', 'what'=>1, 'do'=>3));

It may be more to type, but it is harder to get it wrong when you are using named parameters. You don’t have to remember what each of the parameters do in their specific positions either so it is easier to understand the code as you quickly glance at it. Note that this is similar to the way that a lot of ruby functions are written, except we don’t have a short hand for named parameters like they do (it would be awesome if we did…):

 
myfunction(:a => false, :lot => 1.2, :parameters => { :one => 1, :two => 2 }, :I => 'I', :what => 1, :do => 3)

While this is definitely easier to read and remember, it is probably worth refactoring a function like this (as it is an extreme case) further because it is likely that you are doing way too many things within it.

Uncategorized — 6 Comments
7
Apr 10

An alternative to Poor Man’s MVC in PHP

As written in my previous post ( http://blog.seanja.com/2010/03/re-top-10-php-techniques-that-will-save-you-time-and-effort/ ) I noted that the code for the proper way to write an index file is essentially a Poor Man’s MVC tm.

This method is fine for someone starting out their php journey, it lets them do everything they will probably need to do (they can even add in some apache rewrite rules to make the url look nice). The problem with this approach is that, while it is really fast, it is relying on you to define every single page that you add to your site individually by hand (well, except for the last example). Another problem is that you will inevitably end up with something like this (ok, this might be a bit of an extreme example…):

because the next person to edit the code is too lazy to look at how it actually works. This will repeat itself because the next person after that will figure that is how the code works (ad infinitum).

The alternative is to use an actual MVC pattern, there are lots of tutorials out there to help you reinvent the wheel (which is a great learning tool), or you can start with one that is pre built like CodeIgniter, its cousin Kohana, or one of a pile of others.

It is however, up to you to decide the best way forward for your application, you can use of of the Poor Man’s MVC tm pattern if you really want. If you use it properly, with self control, you will have no problems. It is good to look at other options though, so you can actually understand the advantages and disadvantages of other methods. I find that I like the patterns and organization that are ‘forced’ upon me when I use an MVC framework. It means that I know where the code to control specific actions is, the code for the database/object interactions is over there, and the html (views) is in this spot over here. It makes for easy maintenance, and it makes for faster coding when you know exactly where to go.