Joel Hainley

Mike challenged me to a contest, hopefully this one goes better than the last one.

The challenge : write a web-based application and release it to the world on or before November 5, whoever generates the most revenue between November 5 and January 5 wins. The only other requirement is a weekly development blog posting detailing status and the work on the agenda for the coming week.

The stakes : I think it’s either hot wings at Hooters or Wing Stop and maybe a case of Mountain Dew or Jolt…can you even buy Jolt anymore?

My project : ClikClock a time tracking program. I really want to do a good, solid, well thought out time tracking program because the few I’ve used drive me nuts. Everyone I talk to hates the applications that they are forced to use at work. So I’m going to give it a shot. See if I can make something that’s powerful and easy to use.

Update : I have had several false starts on ClikCLock in the past but I want to get this idea out of my system, because I’ve had thoughts about doing it for so long. I have written a couple of partial implementations and was reasonably happy with how things were turning out. However some business reasons ultimately forced a rewrite on a different technology platform. On May 1 I opened up an editor and started the current implementation of ClikClock. Since then I’ve written my own MVC framework and have integrated Doctrine and Smarty to create a pretty nice framework to do development in. I had to build a lot of stuff in the beginning to get things working that I wouldn’t have had to build if I had used one of the existing frameworks but I had a desire to build the framework and quite frankly it only took between 4-6 hours to build out the MVC framework and It’s WICKED fast.

I have also decided to use git for this project so I’ve been learning that as I go along. So far I like it but I haven’t had to do anything too crazy with it yet.

Tasks for the week :

• New Account Setup wizard
• Account Administration screens
• Build out the Account Configuration system

The first time I did some work with PHPUnit I was writing out tests in preparation for some refactoring. So I put together a bunch of tests for my utility classes, and pure logic classes etc, database access classes, etc. So everything was trucking along wonderfully, things are falling into place and then I run a test that tests some database stuff.

The application was setup with a configuration file that defined all of the database connection information, this file is included by the database library providing a single set of database routines to be shared by the application. Pretty standard stuff here. Perhaps in a nod to the rails/java crowds it could have been put in a non-code file and read in by the application but as far as I’m concerned that’s just personal preference. At some point you’ve got to have some configuration information somewhere and this works as well as anything.

So now that you know how things were setup, we’re back to the PHPUnit test…it bombed, failed, crashed, whatever. After digging into it a bit I discovered that PHPUnit has a problem with munging the global namespace when it runs. Things that are global variables can’t be pulled down into local scope because they don’t exist there anymore. I did some reading and found numerous complaints about this in the PHPUnit bug system, all of them closed with “this issue resolved” when the issue most assuredly had not been solved. I even found a conversation where one of the developers stated that it was not a bug, that the user simply needed to modify their code to work with PHPUnit. Huh? Modify the architecture of your code to work with a testing framework?!?

I spent some time thinking about this and I think it could be said that he’s right, but for the wrong reasons. First off, if this is a technical limitation of PHP then just say so and let it go. If it’s an implementation problem with PHPUnit then say so and try to put together plans to fix it. However, I think in this particular instance the problems that I was experiencing with PHPUnit could indicate a larger problem in my application.

Here’s how..One of the things that I hated when I first started using PHP was having to pull things out of the global namespace into the local namespace to use them. When PHP5 came out and the object model finally had a good amount of maturity I moved to utilizing classes for most of my code and this allowed me to start using the $this operator for accessing a lot of variables that I needed to deal with. In fact, the only place I was really using globals was in my library routines. After thinking about this for a bit I realized that it was much more convenient to wrap all of the configuration data into Singleton then I’d have a single object that I could use to get all data instead of having to pull in everything I needed one variable at a time.

It was at that moment that I realized if I had a singleton that housed all of the configuration data I could instantiate it in all of the routines where I needed to access configuration data and it would avoid the problems that PHPUnit had with the global namespace. When I looked in the todo’s for the configuration file there was an item at the top “Maybe I should turn this into a singleton”…two birds with one stone? Ten minutes of work and I had everything setup and ran my tests and “bingo” everything worked.

So in the end, modifying the way that configuration information is disseminated throughout the system by using a singleton has been “the right thing”. I had some heartache over the responses from the PHPUnit developers about the “solution” to the problem their users were having mostly because the solution involved a lot of extra crap with addressing the global namespace in a particular way. Using a singleton ended up providing the needed functionality, didn’t do anything retarded with variable access, and ended up making the application much cleaner to work with.

There’s no doubt that today web services are hot, all of the commercial platforms ( J2EE, .Net, etc ) have tools that make the development of web services very easy. There are also a bunch of tools that are out there that help people generate their WSDL’s and can generally ease all of the difficult parts of developing web services. The great thing is that with the release of PHP 5 we now have tools that allow us to quickly develop web services in PHP. The great thing about this is that you can stub out api’s and start to have different solutions speak easily among themselves, share business logic to languages and technologies that are “not native”.

Within this article I’m just going to hit some highlights about creating your own web services using SOAP and PHP. I will also provide a URL to a web service that I have written for people to fiddle around with their first SOAP client. Please note that I’m not providing an exhaustive example of all of the details of wsdl’s/SOAP and the like, this is the SOAP equivalent of a “hello world” program, but with parameter passing included since most “Hello Worlds” don’t have parameters passed into them. We’re going to be building a little service that will support 2 operations, rot13 of a supplied string, and the mirroring(reversing) of a supplied string. Nothing terribly fancy, but certainly more interesting than “hello world” .

You can see the WSDL for this service here . There isn’t much to note with the WSDL it is a simple service and I’m not trying to get too crazy here. So take a look at it and see if it makes sense, if not, try to compare it against the code samples below and see if you can determine how it all relates.

Now that we have the WSDL defined it’s time to build the SOAP server to support this WSDL. Here’s the full listing for the server :

Pretty easy to understand, you’ll notice that we are just defining the functions at the top, then once we have created the soap server using the WSDL we simply associate our php functions with the functions defined in the WSDL by passing the function name to the addFunction message of the newly created SOAP server. Note that we have turned off the caching of the WSDL, this is something you’ll wanna do while you’re developing. When you don’t do this and make changes to your WSDL and they never seem to take, it can get frustrating .

Ok with the server out of the way let’s turn our attention to the client. Here’s the listing for a simple client :

I’m sure you could write a fancier example, but it gets the point across. First, You turn off the WSDL caching on your client as well as the server. Then you create a new soap client using the wsdl. Then you just start calling methods that you defined in the server. That’s about all there is to it.

Note, I’m going to keep the Soap Server referenced in this article up for you all to use. Please feel free to use it for testing your clients as you’re getting up and running. Eventually you’ll wanna start using your own servers for more interesting things though

This morning I’ve been thinking about work I’ve done in the past on PHP 4, and some of the projects that I’ve been involved with using PHP 5. The two versions of the php seem miles apart when you’re working with them and have made for some interesting problems. One of the big things that seems like an under the radar change but has overwhelming consequences is changes to the php 5 object model.

For instance, I recall working with some people developing a new feature for their php4 based system, the developer on the project had done all of the initial work on his local box running php5 and figured that they would just upgrade their server to php5 when he was ready to roll out the new feature. However, the company was overly cautious and had put an moratorium on installing php5 on their systems, and the feature had to be dropped onto the php4 system. I was brought in when the developer couldn’t make progress with the system on php4 and was stubbornly trying to get the code to work on php4 because “it worked just fine on php5″. Unfortunately, the developer didn’t understand how deep the changes went in php5 from php4.

If you spend a little bit of time crawling through the php.net documentation website you’ll come upon two entries for classes and objects. Classes and Objects (PHP 4) and Classes and Objects (PHP 5). You can see just from this that there’s a lot of difference between the two versions in terms of objects but what you can’t see in this document is some of the fundamental changes that occurred to make all of this possible.

The largest change in php5 was the move to object representation being done by a handle that refers to the object. This sounds obvious to all of you java, c#, etc..people out there, but in php4 an object was treated as a primitive data type. This resulted in the entire php4 object being copied each time there was an assignment, parameter passing, and returns from functions. This resulted in the programmer spending loads of time trying to wade through the by-reference assignment voodoo.

Now having considered this, let’s go back to our developer porting a php5 application back to php4. He was able to understand all of the syntactic sugar that needed to be modified, and get all of that working pretty easily. However things still didn’t work correctly and he couldn’t wrap his head around the problems.

Do you wanna know what the problem with his application was? Updates to his objects weren’t getting replicated back to the database properly, see this “clone the object” approach of php4 was the basic problem. Once I had him able to see what the real issue was with what he was trying to do, we were able to get things working through a combination of “byref voodoo” and tweaking his object model.

In the end, all things came out relatively well, we were able to get the new features out before the deadline, and things worked swimmingly. It’s interesting to note that if he’d known the details of how php4/php5 worked he wouldn’t have had any problems putting together a slightly modified architecture that would have worked for both without any problems.