Over the weekend I was playing around with CodeIgniter. I was up and running pretty quickly and it all seemed to go pretty smoothly. Having built web applications and web sites for a number of years now and before that desktop applications etc, I’m usually pretty quick with establishing a technical structure for my site. I do this because I tend to work in iterations rather than focusing on one specific thing before moving on the next. Anyway, I became a bit frustrated when I noticed that I couldn’t subdivide my controllers folder. It seemed that I could only have one big pool of controllers. This was no good. I checked the documentation and at first I didn’t notice the section that describes how to divide your controllers folder into sub folders. When I finally had figured it out I ran into the next problem.

My site has a top level menu option called ‘Settings’. When you click ‘Settings’ I want to execute the ’settings’ controller located in the controllers/ folder. The Settings page however has more sub-options like Users, Groups, Roles etc. and I want all these controllers to live inside a settings/ folder that’s located in the controllers/ folder:

+ controllers/
   +settings/
      -users.php
      -groups.php
      -roles.php
   -settings.php

This was going to clash. Going to the localhost/myapp/settings URL would execute the ’settings’ controller and going to localhost/myapp/settings/users would bring up a 404 error page. I assume this is because the framework tries to execute a method called ‘users’ inside the ’settings’ controller.

Going back and forth with this issue I finally figured out a way to overcome this problem. In the routes.php configuration file you can set a default controller to execute. I’ve set mine to ‘index’. So, this could mean that if I would bring my settings.php file holder the Settings controller into the settings/ folder and rename it to index.php, it might execute that controller when browsing to localhost/mysite/settings. And behold, it does. the structure I ended up with was:

+ controllers/
   +settings/
      -index.php  <- default controller
      -users.php
      -groups.php
      -roles.php

I haven’t tried this yet with deeper structures but I assume that the same idea applies to that as well.

I never really had the chance to use Flash Remoting on a commercial project and it has been years since I played around with it. It must have been 2003/2004 or so that I first tried using it. At the time I tried it with ColdFusion, which worked pretty OK, and with Java (JRun to be precise). I was pretty impressed with the level of abstraction that Flash Remoting provided. Not just from the ActionScript point of view but also from the server point of view. No more manual parsing of data structures. Great! Thinking about it, I can’t really understand why it isn’t more widely used. It seems that it is only used on the more corporate websites, or very specialized stuff to say the least, and you don’t see it much used with the ‘typical’ Flash stuff or hear much about it in the general Flash community. Maybe that’s because Flash Remoting is quite a techy thing to get your head around and that it’s out of the league of your typical Flashers. Maybe BlazeDS is going to make a change to this, but somehow I doubt that.

Anyways, I was playing with AMFPHP over the weekend. It was a fair bit of work to get it all up and running. The documentation on the site isn’t what you would call ‘good’ but after a bit of puzzling I was able to figure it out and was able to make a request through Remoting and get a result value back. Awesome. The next thing I wanted to do was to use a bare bone NetConnection instance to connect to AMFPHP. After all, in Flash it’s the only intrinsic object available to connect to an AMF server and somehow the Remoting classes provided by Adobe seem to be so incredibly complicated and not intuitive to use at all. Luckily they changed this for ActionScript 3, but I wanted to figure this out for ActionScript 2.

The first mistake I made was to focus on the connect method of the NetConnection object. I figured out that the NetConnection has an undocumented onStatus event handler. I figured also out that when I made a connection the onStatus wasn’t triggered when I used http, only when I used rtmp. Hmmm, that was kinda odd. I played around with it for a while and decided to move on to the next thing, which was calling a remote method. I created a simple HelloWorld method on the AMFPHP server and called it using the Remoting classes provided by Adobe. That worked fine. So I set up the following code using a bare bone NetConnection:

var responder : Object;
responder = new Object();
responder.onResult = function( result : String ) : Void
   {
      trace("responder:onResult " + result);
   };
responder.onStatus = function( info : Object ) : Void
   {
      trace("responder:onStatus " + info.code + ", " + info.level);
   };

var nc : NetConnection;
nc = new NetConnection();
nc.onStatus = function( info : Object ) : Void
   {
      trace("nc:onStatus " + info.code + ", " + info.level);
   };
nc.connect("http://localhost/remoting/gateway.php");
nc.call("HelloWorld.say", responder);

Now, this is where I went on my next wild goose chase. I spent the next couple of hours trying to figure out why this didn’t work. Going back and forth between the test case I did with the Adobe classes and this example. I just couldn’t figure out why the NetConnection example wasn’t working. I made dozens of small changes, trying to isolate the problem. But alas. Nothing. Until, at one point, I decided to change this line:

nc.call("HelloWorld.say", responder);

To this:

nc.call("HelloWorld.say", responder, "hello");

Bang! It worked. Apparently, just because the signature didn’t match previously with any remote function on the server, the function simply wasn’t called… Maybe it’s my naivety, but I was expecting the parameter to be just passed as an empty string, or null, if not specified. I’m currently not sure where the problem lies with that, but I guess it’s with AMFPHP. I think AMFPHP is to strict on signature testing and should be a bit more relaxed when it comes to that. I played around with it a bit more and decided to call it a day.

Today, while doing the dishes, or better, cleaning out the dishwasher the http/rtmp problem just solved itself. Of course the behavior was different! When connecting to an AMF server through http, the connection is stateless and can’t be maintained. In fact, calling the connect method on the NetConnection object doesn’t actually do that much and behaves completely different than with rtmp. It does call the server, but it seems to only check if the location, or gateway you want to call, exists. Only over an rtmp connection the Flash Player can maintain an open connection with the server. Duh!

I will definitely be using more Flash Remoting in the future and will most likely try to push it for more commercial projects from now on. It’s a great technology, saves heaps of bandwidth and no more XML/JSON parsing!

I used to hate PHP. I still do actually, even if it’s only just a bit. But, over the past year or so I’ve developed an appreciation for the language. OK, as a programming language it is pretty odd. I mean that syntax, c’mon. Some weird demon child offspring between C and Perl. It’s a pretty hideous creature. Furthermore, PHP cannot be considered a platform like .NET or J2EE. It’s a programming language, nothing more and nothing less. Anything you can code with PHP can be done in as many different ways as there are PHP programmers. In a way it reminds me of the good old C days. C came with a massive library of incoherent functions. E.g. with C there where multiple of different ways of working with files. You use the set of functions that would make to most sense to you. In a sense, the biggest difference between PHP and C is the lack of pointers…

I believe that the power of PHP doesn’t lay in the programming language itself, because any serious programmer can confirm that the language is pretty frustrating to work with on a day to day basis. No, the power of PHP lies in its availability. A programming environment like ColdFusion, Java or even .NET is much more powerful and structured. Not that you can do more with these languages than with PHP, but it provides a common ground for programmers to start off with. The problem with ColdFusion and Java is that you can’t get it hosted, unless you’re willing to shell out the big bucks. Most providers offer Windows hosting so hosting ASP isn’t outside the reach of small time web developers and whipping up some old school ASP isn’t that much different than doing PHP. With .NET that’s a different story. Unfortunately, to effectively develop for .NET you need the Visual Studio development environment which you can buy for lots of money from Microsoft, making the platform unavailable for a large group of developers. I’m sure Micorsoft provides a stripped command-line SDK, but that doesn’t make the environment more approachable for people who don’t have the budget to buy Visual Studio.

The typical web developer likes PHP because every cheap hosting enviroment has at least PHP 4. And even though PHP 4 lacks some OO functionality, you can create pretty good applications with it. Other than that, there is so much information available for PHP available that’s being able to be grasped by not only the hard-core coders but also the the guy who just wants to store some stuff in a database and doesn’t want to get to much involved in the details of the language. Because of this, there are a lot of web developers using PHP. Which in turn means that a lot of companies use it because it has a large resource pool. So, even though PHP isn’t the most elegant programming language, it is popular because of these reasons.

For the past week I’ve been working hard on the CoreTween website and the CoreTween library. Small changes where made to the CoreTween library and a new reference section has been added to the website.

One of the problems I was facing with the CoreTween reference documentation was the fact that CoreTween supports four different languages. Because 90% of the documentation is the same for all four languages I need some sort of scheme that wouldn’t involve duplicating any data. My first choice was of course to store the reference documentation in a good ‘ol database. But to do that effectively I also needed some sort of CMS through which I easily could fill this database. No of the shelf solution fitted this so I reverted to another solution.

For a long time I’ve been wanting to do more (and learn more about) XSLT. This fascinating XML technology has been on my mind a lot lately and so I decided that this would be a good time to start using it. The reference documentation for CoreTween is therefore stored in a simple plain XML document which is easy to edit with a normal text editor. The XML Stylesheet then converts this XML document to the appropriate HTML document containing the correct implementation language (ActionScript 1, 2, 3 or haXe). Within the XML document there are tags that look like this:

<if>
   <as3>
      void
   </as3>
   <otherwise>
      Void
   </otherwise>
</if>

This way its easy to specify only the differences between the supported programming languages and keep all the other stuff the same. The XML Stylesheet takes care of filtering the <if> tags to the correct value. These vales are passed from the URL to the PHP script that executes the XSLT processor. Try a sample of the TweenManager class for a demonstration. To change to implementation language, simply change the ‘language’ parameter on the URL to as1, as2, as3 or haxe. Follow this link to have a look inside the TweenManager XML document that defines the reference documentation.

Of course, on the final website you can easily change between implementation languages. But that’s still in the works.