So a user signs up and I want to store a status that reflects their account, or at least an identifier representing that status. Their account could be active, disabled (temporarily), pending approval or maybe deleted. Should I use an enum? I've heard they're evil. Maybe having a reference table with statuses would be better? But now I have to manage a separate table just for that one snippet of data, is that overkill? Could I maybe use that status table for other entities? Or, could I instead just use an integer and reference it on the code level? What is the right solution?

He presents three of the most common situations he's seen for people using enums in the application:

• "I used enums all over the place" (maintenance between code and DB values)
• "use a reference table"
• "I could use a class constant to represent the enum" (enforced in the app)

Of the three, he suggests the third as the option with the most advantages. Not only does it make it simpler to get the allowed values for the field, but you're also more flexible in the kinds of validation you can do on the values.

When upgrading the unit tests I had no problem, it was only when I was trying to integrate into CruiseControl that this was happening. Well after some time, I finally figured out the issue was the "ant" command to execute the unit tests was passing the -process-isolation flag to phpunit.

He found that when he called it with that flag, it was executed twice, resulting in the "already defined" message the second time. He fixed it by removing the extra flag. Another alternative is to wrap your constant definitions (and anything that dosen't need to be called/created again) in an "is defined" check.

I know that there are a lot of posts now about namespaces in PHP 5.3. This is mine which is how I learnt how they work. [...] That is, namespaces allow us to: combine libraries with the same classnames, avoid very long classnames and organise our code easily. Note that namespaces do not just affect classes. They also affect functions and constants.

He starts with the basic namespace definition (using the "namespace" keyword), shows how to import another namespace with "use" and the use of the __NAMESPACE__ constant to determine what namespace you're operating in. More information on namespaces can be found in the PHP manual.

Static helpers seem to be a great idea at first glance, as they're reusable components that don't require any kind of expensive instantiation for doing common tasks [...]. But the sad and unavoidable truth is in many cases they're simply wrappers for procedural code, which has been elegantly hidden behind a "class" construct. So what's wrong with this? Well, even in the most harmless situations, when you use a static helper that produces a deterministic output, you're actually throwing away the advantages that OOP provides.

To illustrate, they create a basic validation class that can check for things like valid emails, float values, integers and URLs using PHP's filter_var function. They point out that the class is difficult to extend and that it is doing too many things to be correctly considered a "piece" of functionality. To correct the problem, they opt for a different approach - an abstract class acting as an interface to structure custom validators against. This provides set/get methods for things like the error message and value to evaluate. The implementation of the validators on top of this class is coming in the next part of the series.

One of the decisions that has to be made each time an application is written for distribution is how best to set up the configuration files. There are a number of different approaches taken to this: some opt to use the define() function and define constants, while others use large arrays.

He points out a few "overlooked options" that some developers might no consider when working with configuration files like class constants and ini files (which PHP can parse natively). A few code snippets are included to show examples of them in use.

I was running into a few errors, and getResultCode() was obligingly returning the value of the constant, rather than the constant itself. I had to look up what that value meant. For some reason I couldn't reflect the extension to get the constants and values thereof, so with some lame scraping you get the following.

He's included the list in both a normal text format and as a PHP array that can be cut and pasted directly into a library.

Over the last few days I have been digging deep into the concepts of REST. I have been reading through my copy of RESTful Web Services. Out of curiosity I searched Google for a "php REST library" and it turned up the Official MySpace PHP REST Library.

He points out one interesting thing about it, though - it's like they started using an object-oriented design but build after making the classes with properties. No methods.

Even if they were to choose to go the PHP 5 way I would highly suggest that they do not use classes as containers for constants, there is no need to do this. It is not using proper OOP methodologies. Why create an object that just holds 2 - 4 constant variables, these would be better suited for define() calls in my opinion.

Magic methods, which are class methods with specific names, are used to perform various specialized tasks. They are grouped into two: overloading methods and non-overloading methods. [...] Magic functions, which are similar to magic methods, but are just plain functions outside any class. [...] Magic constants, which are similar to constants in notation, but act more like "dynamic" constants. We'll also look at some practical examples of using some of these, and lastly we'll check out what new features PHP 5.3 is going to add.

He looks at the various functions/methods and constants (like __clone, __toString), some of the overloading methods like __call, and magic constants like __FILE__ and __CLASS__. He wraps it up by briefly discussing what PHP 5.3 adds in - a few new magic methods and constants (but no functions).

That's how this new post on the PHP in Action blog starts this morning. The one thing that he wants is enumeration support in PHP. He shows how it can currently come close with a "roles" system:

Useful examples I've encountered in web programming are states or stages in a process and user roles. Another kind of example is one I used in PHP In Action: an authorization system with three fixed roles or categories of user: regular, webmaster and administrator.

He sets up an example class that sets constants for the different access levels rather than just relying on strings to handle it (which, as he points out, could very easily be misspelled and not throw any kind of error) .

There are thousands of services available on web who are presenting interesting as well as education information which you can really integrate in your web page or make a nice widget and let others use them seamlessly with their content delivery platforms. In this article I am going to show you how you can make a nice Today-in-History widget with the help of the data provided in Scopesys.

He wisely recommends that you check one thing first about the content you're grabbing - the copyright it carries with it. This could get you into big trouble down the line depending on whose content it is. The actual script is pretty simple - he defines some constants as markers for where things start and stop in the HTML and then uses strpos to get the locations for his substr call to grab the segments.