So what’s so great about that? According to Andi Gutmans of Zend, having the two programs bundled together will provide a seamless experience end-to-end, creating apps deployable to Android devices with support for iOS and Blackberry devices shipping within 60 days. Even though this is not a pure “write-once-deploy-everywhere”, this will save considerable time and resources. Instead of three completely separate apps for the three separate platforms, you will be able to use one code base within Flash Builder to deploy natively to all three mobile platforms and the web. Dave Gruber of Adobe estimates there will be upwards of 70% code reuse across all platforms (mobile and web).

And the best news beyond that is integrated debugging. Flash Builder 4.5 will be able to handle debugging for all your platforms – desktop, IDE, server-side PHP and device – all in one session.

Everything described above will be available for Windows (XP SP3 or higher) and Mac OS (OSX v10.6 or higher). See the Adobe website for the full list of requirements. The Standard version of Flash Builder 4.5 will cost $399 USD. There will also be a Premium version for $799 USD which will also include memory and performance profilers, a network monitor, and a unit testing harness to connect to major unit testing frameworks. Both the Standard and Premium versions will be available for sale through either Adobe or Zend. There are company-specific upgrades available as well. If you already have Flash Builder, upgrades are available for both versions for $299 USD through Adobe’s website. Current Zend Studio users can contact the Zend Sales team to receive discounted pricing on upgrading to Flash Builder.

Before all else, write the code

To keep this simple, I will follow the same rules as before, I will not attempt to add or delete users, just list them and then allow them to be edited. We will call our class WPUser.

As before, for Flex to be able to inspect it, it has to be within the webroot of your project.

class WPUser
{

    protected $db;

    /**
     * @return void
     */
    public function __construct()
    {
        $this->db = mysqli_connect('localhost','root','','wpmu');
        return;
    }

When we create the class, let’s go ahead and create a connection to the database. Let me make a couple of notes here for those who might be concerned by that line. First, this code is running on my local machine against my test database. So yes, root is the user I use and there is no password on it. This is not a best practice. Please don’t copy and paste that code and just add your root password.

Second, if I were building a real application, I would use dependency injection to had my model a connection to the persistent data store. However, this is simple example so I am taking a few liberties. Again, please don’t copy this code verbatim and use it.

    /**
     * @return array
     */
    public function listUsers()
    {
        $stmt = mysqli_prepare($this->db, "SELECT * FROM wp_users");

        mysqli_stmt_execute($stmt);

        $rows = array();

        mysqli_stmt_bind_result($stmt, $row->ID, $row->user_login, $row->user_pass, $row->user_nicename, $row->user_email, $row->user_url, $row->user_registered, $row->user_activation_key, $row->user_status, $row->display_name, $row->spam, $row->deleted);

        while (mysqli_stmt_fetch($stmt)) {
            $row->user_registered = new DateTime($row->user_registered);
            $rows[] = $row;
            $row = new stdClass();
            mysqli_stmt_bind_result($stmt, $row->ID, $row->user_login, $row->user_pass, $row->user_nicename, $row->user_email, $row->user_url, $row->user_registered, $row->user_activation_key, $row->user_status, $row->display_name, $row->spam, $row->deleted);
        }

        mysqli_stmt_free_result($stmt);
        mysqli_close($this->db);

        return $rows;
    }

Ok, our listUsers() function is next. If you are paying attention, you will notice that it looks a lot like the one in the prototype class that FB4 generated. That is because it is good example code so why re-write it? The important thing to note here is the docBlock comment at the top. FB4 doesn’t actually know anything about PHP code. Instead, it relies on the docBloc comments to figure out parameters and return types.

To show the results of incorrect settings in a docBlock, I’ve changed the return value to string for listUsers()

    /**
     * @return array
     */
    public function listUsers()

Now, trying to attach our data grid to our new WPUser class will show this error:

You can see that the return type for listUsers() is now reported as String even though I’ve not actually changed the code. Since string is not an acceptable return type for a DataGrid to process. So make sure the docBolcs are not only correct, make sure that the return value you are specifying is valid for the intended use.

Now, let’s look at the code for fetchUser(). This method shows us how to specify a parameter sot ha FB4 can pick it up.

    /**
     * @param int $id
     * @return array
     */
    public function fetchUser($id)
    {
        $stmt = mysqli_prepare($this->db, "SELECT * FROM $this->tablename where ID=?");
        mysqli_stmt_bind_param($stmt, 'i', $id);
        mysqli_stmt_execute($stmt);
        mysqli_stmt_bind_result($stmt, $row->ID, $row->user_login, $row->user_pass, $row->user_nicename, $row->user_email, $row->user_url, $row->user_registered, $row->user_activation_key, $row->user_status, $row->display_name, $row->spam, $row->deleted);

        if(mysqli_stmt_fetch($stmt)) {
            $row->user_registered = new DateTime($row->user_registered);
            mysqli_close($this->db);
            return $row;
        } else {
            mysqli_close($this->db);
            return null;
        }
    }

Again, making sure you get these correct is the secret to making sure the docBlocs are correct.

Rounding out our WPUser class is the update() method. This takes as a parameter a stdClass. Behind the scenes, FB4 is using Zend_Amf (Remember when we installed Zend Framework?) to communicate with PHP using the Action Message Format. This allows it to serialize classes in FB4 pass them to PHP and unserialize them.

    /**
     * Updates the passed item in the table.
     *
     * Add authorization or any logical checks for secure access to your data
     *
     * @param stdClass $item
     * @return void
     */
    public function update($item) {
	$stmt = mysqli_prepare($this->db, "UPDATE $this->tablename SET user_login=?, user_pass=?, user_nicename=?, user_email=?, user_url=?, user_registered=?, user_activation_key=?, user_status=?, display_name=?, spam=?, deleted=? WHERE ID=?");
	throw new Exception(mysqli_errno($link), mysqli_error($this->db));

	mysqli_stmt_bind_param($stmt, 'sssssssisiii', $item->user_login, $item->user_pass, $item->user_nicename, $item->user_email, $item->user_url, $item->user_registered->toString('YYYY-MM-dd HH:mm:ss'), $item->user_activation_key, $item->user_status, $item->display_name, $item->spam, $item->deleted, $item->ID);
	throw new Exception(mysqli_errno($link), mysqli_error($this->db));

	mysqli_stmt_execute($stmt);
	throw new Exception(mysqli_errno($link), mysqli_error($this->db));

	mysqli_stmt_free_result($stmt);
	mysqli_close($this->db);
	return;
    }

}

Changing out Data Connections

Now that we’ve created a class that we can hook a Data Connection to, let’s setup our application to use the new one instead of the old one. Follow the instructions in part 1 of the article with one exception. Do not have it generate a sample class. Instead, click the Browse button and find the WPUser.php you just created. Once you do, the wizard should look something like this:

If everything looks correct, go ahead and press Finish and you will see the new Data Service in the Data Services panel.

To make it the data service for your Data Grid, click on the grid. A small icon will appear in the upper left corner like this:

Clicking on that icon will bring up a dialog that will allow you to select WPUser service. Once you do that it will need to test the call and gather information on the return value. Clicking on the “Change return type…” link (as highlighted below) will bring up a dialog that will walk you through the two steps for automatically discovering and setting the return type.

Once you’ve done that, your data grid will now be using the WPUser data service instead of the original Wpusersservice service.

Wrapping it up

I’ve attempted to give you a taste for the different things that the Data Connection Wizard can do for you when working with PHP files. In the right hands, it is a powerful tool and can save developers time and headaches. However, there are some limitations you have to be able to work with to use it.

The main one, as I’ve pointed out and discussed in previous articles, is that all of your PHP code has to be accessible in your web root. FB4 will attempt to explore your code to analyze it but it does so by opening each file and reading it as opposed to using PHP’s native reflection methods to gather this info. This isn’t a problem as long as you realize it.

In a future article we will examine the alternative to using the PHP Data Connection Wizard, the HTTP Data Connection Wizard.

…and yes, I still dislike Harry Potter. Not as a person mind you. Wizards in real life as well as in fiction tend to annoy me. I don’t like magic when it comes to my code, I want to see what is going on.

Callbacks rock in ActionScript

I am the first to admit that I am still trying to get my head around the concepts behind event driven programs. I’ve been knee deep in web for so long that a lot of these concepts are still not coming to me. One of the problems I am facing is how to different components, that know nothing of each other, talk to each other? Also, with asynchronous tasks taking place, how does component A know that component B has completed it’s task. The answer to both of those questions is ‘callbacks’.

In PHP we use the Observer pattern in cases to solve problems. Callbacks are an implementation of the Observer pattern in that one component tell another component, “tell me when you are done” or “tell me when something changes”.

My current project

I want to write an AIR program that looks at the twitter stream, searches for images, (I’ll use yfrog but you can easily add twitpic or any others) caches them locally and then puts them up on the screen with a nice little animation. What I have right now is a very ugly application that fetches the last 20 tweets that mention yfrog.com. The point of this milestone was to show that I could separate the logic into classes and have the classes talk to each other.

TweetFetch

Ok, here comes the first batch of code. This is the main class that talks to twitter. It is in no way a complete twitter API wrapper for ActionScript. It simply calls the search, stores the results and processes callbacks.

package com.calevans
{
	import mx.rpc.events.FaultEvent;
	import mx.rpc.events.ResultEvent;
	import mx.rpc.http.HTTPService;
	import mx.controls.Alert;
	import mx.collections.ArrayCollection;

/*
 * Fetchs all the images in the current timeline.
 */

	public class TweetFetch
	{
		protected var _service:HTTPService;
		protected var _data:ArrayCollection;
		protected var _responseCallbacks:Array;
		protected var _faultCallbacks:Array;

		public function TweetFetch()
		{
			trace('TweetFetch');
			this._service = new HTTPService();
			this._responseCallbacks = new Array();
			this._faultCallbacks = new Array();
			this._service.url = 'http://search.twitter.com/search.atom';
			this._service.addEventListener(ResultEvent.RESULT, response );
			this._service.addEventListener(FaultEvent.FAULT, fault );
			this._service.showBusyCursor=true;
		} // public function TweetFetch()

		public function fetch(query:String):void
		{
			trace('TweetFetch::fetch');
			var params:Object = new Object();
			params['q'] = query;
			this._service.send(params);
			return;
		} // public function fetch(query:String)

		public function response(response:Object):void
		{
			trace('TweetFetch::response');
			this._data=response.result.feed.entry;
			if (this._responseCallbacks.length>0) {
				for (var i:int=0;i0) {
				for (var i:int=0;i<this._faultCallbacks.length;i++) {
					this._faultCallbacks[i](e);
				}
			} else {
				Alert.show(e.toString());
			}
		} // public function myfault(e:FaultEvent):void

		public function registerResponseCallback(f:Function):void
		{
			trace("TweetFetch::registerResponseCallback");
			this._responseCallbacks[this._responseCallbacks.length] = f;
			return;
		} // public function registerResponseCallback(f:Function):void

		public function registerFaultCallback(f:Function):void
		{
			trace("TweetFetch::registerFaultCallback");
			this._faultCallbacks[this._faultCallbacks.length] = f;
			return;
		} // public function registerFaultCallback(f:Function):void

	} // public class TweetFetch

} // package com.calevans

One of the first things I hope you notice is all the trace() calls. Because we are dealing with events and async processes, I find it easier to understand what is going on if I put a trace at the beginning of each method. That way I can actually see the order of execution.

The code above works. It worked about 5 minutes after I wrote it (I did have a couple of errors working with the API) but I didn’t understand how to hook it back into the main application. That is when I started reading up on callbacks.

Functions are objects…just like everything else

One big difference between PHP and ActionScript (and I beleive JavaScript) is that functions are objects in ActionScript. This means that I can pass a function as a parameter. I’ve not investigated deeply but I beleive these are passed by reference and not by value. Therefore, I can not only pass a function in as a parameter of another function, I can store that function reference, pass it around and even call it. That, in my book, is pretty dang cool. (I am easily amused)

You will see in the cod above a function registerResponseCallback() (and it’s conunterpart registerFaultCallback()) As the name says, this is were you tell TweetFetch what to do once it has successfully fetched and stored the tweets. I will show the full twallpaper.mxml later, for now, here is the snippet form it where I actually register a callback.

tweetFetch.registerResponseCallback(processNewTweets);

It is that easy, well almost. There are a couple of things you need to know. First, obviously processNewTweets() needs to exist. Second, it need to accept the proper parameters. In this case, when the callbacks are processed, they will each be called, passing in an ArrayCollection so processNewTweets() has to accept a single parameter of an ArrayCollection.

fetch() at line 32, is the main function of this method. Calling hat with a query will set things into motion. It makes the call to the HTTPService. When HTTPService returns successfully, it fires result(). result() stores a subset of the result that comes back from twitter and then looks to see if there are any registered callbacks. If there are, it calls them with this line:

this._responseCallbacks[i](this._data);

this._responseCallbacks[i] this contains the pointer to the function. (this._data) This is the parameter list to pass in. This is what I meant about callbacks being cool, it is that easy.

Do the deed

Ok, you understand the code, you see now how to create a callback that TweetFetch can fire so that the interface can be updated as things happen. Here now, is the main twallpaper.mxml so you can see how I put it all together.

<?xml version="1.0" encoding="utf-8"?>
<s:WindowedApplication xmlns:fx="http://ns.adobe.com/mxml/2009"
					   xmlns:s="library://ns.adobe.com/flex/spark"
					   xmlns:mx="library://ns.adobe.com/flex/mx" creationComplete="init(event)">
	<fx:Declarations>
		<!-- Place non-visual elements (e.g., services, value objects) here -->

	</fx:Declarations>
<fx:Script>
	<![CDATA[
		import com.calevans.TweetFetch;
		import mx.events.FlexEvent;
		import mx.collections.ArrayCollection;
		import mx.rpc.events.FaultEvent;
		import mx.controls.Alert;

		public var tweetFetch:TweetFetch = new TweetFetch();

		protected function init(event:FlexEvent):void
		{
			trace('init');
			tweetFetch.registerResponseCallback(processNewTweets);
			tweetFetch.registerFaultCallback(oops);
		}

		public function mainButtonClick():void
		{
			trace('mainButtonClick');
			tweetFetch.fetch('yfrog.com');
		}

		protected function oops(e:FaultEvent):void
		{
			trace('oops');
			Alert.show(e.toString());
			return;
		}
		protected function processNewTweets(data:ArrayCollection):void
		{
			trace('processNewTweets');
			for(var i:int=0;i
</fx:Script>
	<s:Button x="251" y="83" label="Button" click="mainButtonClick()" />
	<s:TextArea id="myTextArea" x="0" y="125" width="573" height="490"/>
</s:WindowedApplication>

I have said it before but I will reiterate it this is prototype code. The current interface is only to show that TweetFetch is working. So yes, it’s ugly. It does show that the underlying code is working however and it shows a very simple example of callbacks.

One note, I have implemented callbacks for faults as well. Just to show that they are working, I added the function oops() that simply pops an alert box, the same behavior that happens if there is no registered callback. This is just to show the functionality, neither oops(), nor the Alert box will survive into the final code.

Wrapping it up

The problem I had in this particular instance was, how do you update the interface when an async task in an object completes. In my previous examples, all my code was in the main mxml for ease of understanding but as I began to move things out into classes and began to normalize my application, I found new problems presenting themselves. Events, which I will talk about in another post, and callbacks make solving those problems very easy. As this starts to sink into to my web-soaked brain, things start to make sense.

For context: Prior to starting this exercise, I had zero experience in Flash, Flex, and everything similar. I’ve caught a few of Ed Finkler’s presentations on RIA but I’m definitely not a desktop developer.

First, getting setup was ridiculously easy. I downloaded the 60 day trial of Flash Builder 4 and registered to get a full license as a user group member. After a quick activation, I was setup on Windows 7 in a matter of minutes. Of course, that’s where the first oddity creeps in. I’ve used Eclipse for 7 years on both Windows XP and Ubuntu but Flash Builder 4 only works on Windows. It seems like they’re missing one of the best parts of Eclipse as a platform. Regardless, getting started on my first project was identical to starting any Eclipse project.

Next, I had to choose where to start. Since we use iCal for broadcasting Task/Todo information, it was the obvious and easiest place to start. I envisioned a simple list of tasks, a textarea to add a comment, and finally a timer to create a complete tasklog. To do this one, I switched into Design Mode and browsed the components. If you’ve ever worked in a visual editor – such as Dreamweaver or with Visual Basic – the options and configuration is pretty much what you’d expect. You get standard components such as TextArea and DateChooser that you’d expect, but you also get a ProgressBar, ColorPicker, and RichEditableText box. While I won’t use them this time around, it opens some options for later.

Of course, this is where I learned a useful little trick. Unlike PHP where you might echo (or print_r) your value, Flex doesn’t work the same way. You can’t just tell it to echo things without errors and other things appearing. Therefore, I added a TextArea named txtJunk and added this:

txtJunk.text += “my debug message \n”;

where I wanted to know what was happening. There are certainly more advanced and efficient ways of debugging but we’ll cover that another time.

Next, before I can log any time against a Task, I need to get the list of Tasks. The Data Connection Wizard – covered in depth by Cal – seemed like the best place to start. I started up the Wizard, selected HTTPService, configured the URL, and everything worked beautifully and everyone lived happily ever after.

No wait, it didn’t.

If you look closely at the HTTPService in the Wizard, you’ll see that it’s specifically for XML or JSON. Since iCal is a glorified text file, it doesn’t fit into either of these and it failed spectacularly. On the positive side, since the Wizard immediately attempts to validate the data returned, I found out pretty quickly. After a few failed trials to do some form of useful validation, I realized the solution was much simpler than I thought. By setting String as the return type, the DCW allows for literally anything to come back. While this worked, I should obviously look into some JSON or XML structure to take advantage of the validation.

Next, I had to do something with this long iCal string. For this, I dropped out of Design Mode and went directly to the source. At first glance the source looked a little odd compared to PHP. The syntax itself is OO and the naming is consistent and mostly predictable, but it’s the little things that make all the difference. ActionScript is strongly typed so at initialization you have to declare a variable’s datatype. At first pass, this seemed excessive and a little annoying to have to match return types, but there is a huge benefit gained as a result: code completion. And this is one of the places Flex Builder shines. Not only does it have the functions themselves but it includes some basic documentation, the return types, and related details that you’d expect. I had forgotten how helpful code completion is when you’re not familiar with the language.

From here, it became a simple matter of parsing the big string into a series of smaller strings. First, I split it into individual event listings, then into the individual lines of information for each event. Coming from a PHP background, it was ridiculously simple. Granted, some of the syntax and specific method names were a little obtuse at first, but code completion got me 95% of the way with almost no effort.

Finally, I had to wire the whole thing together and this is another place where Flex development is completely different than PHP development. Flex doesn’t use the request/response model unless it’s interacting with external sites or services. Instead, Flex – like all desktop development – is event-driven.

It’s a shift to wrap your mind around writing code triggered from and waiting for events as opposed to responding to requests. Even more odd was the sense that I had lost control over the flow of the application. In PHP development, the code executes from top to bottom, so it’s easy to know what has executed previously and what will happen next. In Event-driven Programming, the Events can happen independent of one another. For example, you can type (an event) in your browser’s address bar even while a site is loading (another event). These events come from all over the place, whether its from a user (typing or selecting an element), a Response from a previous Request, a notification from another Event, or a variety of other things. Therefore, your components have to execute (or fire) independent of one another.

That said, the visual editor handles the basics for you. In Design Mode, right-click on any element and you can interact with the relevant handlers for things like creationComplete, click, change, and a select. If you’re familiar with Javascript development, you’ll notice there parallel with onLoad, onClick, onChange, and similar events.

At present, this code doesn’t do much of value but the next phases will be more interesting and complex. I have to work through what to cache locally and since assigned tasks change frequently, it has to be checked frequently. More importantly, for this client to be useful, it should be able to work offline and not require connectivity immediately at startup. Therefore, we’ll need persistent storage like SQLite and a way to synchronize with the central server.

If you’d like to follow the continuing adventures, the entire source will be available here: http://github.com/caseysoftware/web2project-air and I’ll continue documenting the progress in this space.

Disclosure: Through Blue Parabola, LLC, I’m working with Adobe and a number of their tools and technologies to see what I might be able to use where. I’m under no obligation to be positive or negative with respect to any particular product or person.

The one day training course is available in the cities below. The registration fee includes over 7 hours of training within a small group (so you get the attention that you need), hands on labs and a printed courseware book that you can take back to work for reference later. Lunch will be provided at the training facility along with beverages and morning and afternoon snack.

For more information and to register, click on over to the Adobe Developer Connection.

However, of late I have been working with Flex Builder 3 and now Flash Builder 4 (FB4). While wizards for programming might not be the norm for PHP developers, Flash and Flex developers apparently do like them. To be honest, after working with FB4 now for a few weeks, I am starting to see that wizards aren’t all bad—in fact, some of them are even kind of cool. In this two-part post, I want to talk about connecting Flex applications to server-side PHP APIs using the Data Services wizard that ships as part of FB4.

The Old Way

First, let me say that, as nice as the new Data Services are, I worked with Flex Builder 3 and really liked the old way of connecting to data services. The HTTPService object was super flexible and very simple to use—in fact, when I first started working on the code for this series, it was my intention to prove that the new way was inferior to the old way. It’s funny how technology can surprise you sometimes.

In Flex Builder 3, the way you connected to an API (XML or JSON usually) was to use something like this:

<s:HTTPService id="twitter"
               showBusyCursor="true"
               fault="showFault(event)"
               result="doSomething(event);"
               url="http://example.com/myapi" />

See, that is easy. There is no behind the scenes magic: like PHP, I can get what I need done, done and move on to the next task. I’ve built several AIR and AIR2 applications using HTTPService as my multi-tool for connecting to the outside world because it is just so easy to work with; I like simple tools and HTPService was as about as simple as it got. This is why I was nonplussed when Adobe added “Data Services” to Flash Builder 4.

The New Way

When you first create an FB4 Application, you will immediately notice a difference from Flex Builder 3, the “Declarations” section of the code

<fx:Declarations>
<!-- Place non-visual elements (e.g., services, value objects) here -->
</fx:Declarations>

FB4 now divides your declarations from your visual elements. That is the first thing you have to get used to. It is still easy to hand code an HTTPSerivce—you just have to put it in the new <fx:Declarations> section.

This is still my favorite method for connecting to third party web services like Twitter’s API (the Hello World of Web 2.0). Fetching data like this is dead simple, but, if you want to get into more complex operations like updates and deletions, you inevitably end up writing code by hand. Depending on the API you are talking to, this can quickly become tedious and, if you are a good OO programmer, it will most likely mean encapsulating all of this in its own class. If that sounds familiar, the new Data Services option is going to save you a lot of time and hand coding.

Figure 1: Connecting to Data Services

The “Connect to Data Service” button is on the upper right of the Data Services tab. Clicking that button will open the wizard and help you get connected.

Figure 2: Selecting Service Type

The first thing you have to do is select the type of service you are connecting to. PHP is one of your options. Selecting PHP will require you to point the wizard to the actual class you will be talking to so that it can use PHP’s reflection to gather information about the class. This means that if the API is hosed on a server you don’t have access to; you will need to use HTTP instead. While this will negate some of the benefits of the wizard, it will still set things up for you and you can manually configure your Data Service.

Figure 3: Configuring PHP Service

NOTE: For some reason, the class has to be inside your web root. Since this is considered a bad practice, you probably wouldn’t normally have the class available where Flash Builder 4 is looking.  I feel confident that the answer to this conundrum is a simple configuration setting but I’ve yet to find it. For the purposes of the demo, I put everything inside of web root. I will post a follow-up post once I have a solution for this problem.

Once you have entered a class location, it will attempt to use PHP’s Reflection to pull out methods, parameters and return types. To do this, Flash Builder 4 needs Zend Framework. If you have not already configured it, you will get the following dialog box:

Figure 4: Install Zend Framework

If you already have Zend Framework installed on your system you can save yourself ~20MB by pressing cancel, backing out, finding amf_config.ini and setting the zend_path setting.

For the purposes of demonstration, let’s have it generate a sample class for us. (See Figure 3), Again, everything needs to be inside the web root for things to work properly.

NOTE: This feature is for prototyping only! The program warns you, and for good reason, that you do not want to use this code in production, ever, for any reason, period.

Figure 5: Generate a sample PHP class

Flash Builder will generate the PHP class plus all the necessary ActionScript code to manipulate a table in your database. The resulting class will have your database credentials hard coded in it and will be in your web root. You can see why it’s not a good idea to use this code in production now.

That having been said, I gave it the wp_user table from a test install of WPMU I have on my local machine and it did a good job. The PHP code is quite good. It is primarily procedural code wrapped in an object wrapper but it for prototype code, it’s good.

Since FB4 uses PHPDoc blocks as part of its introspection process, it generates the appropriate docblocks for each of the methods. In my case, it generated 6 methods necessary to add/edit/delete and list the users of my test blog. More importantly though, the wizard created 2 ActionScript classes necessary to talk to the API, _Super_WpusersService.as and WpusersService.as, both in the Services directory. The first one, _Super_WpusersService.as is where the code necessary to talk to the API is hosted. The header comment makes note that this is generated code and should not be edited. It can however, be regenerated at will. The second file, WpusersService.as, is where any customizations go. It is this class, a subclass of the first class and  is the class that is actually instantiated. You can override any of the methods and add your own functionality here. This is a verbose but overall well-thought-out solution to having generated code will still allowing for modifications.

Conclusion

As you can see, connecting to PHP code from Flex is actually much easier in Flash Builder 4 and now you actually have more options with the ActonScript  classes being automatically built for you. The old way of doing things still works and there are legitimate cases where it is the best answer. However the new Data Services wizard does have some nice benefits.

Rose first discusses what Adobe Flex is (in essence, an open-source framework used to build Rich Internet Applications, or RIAs) and gives some background on what’s new in Flash Builder 4 (renamed from Flex Builder)—things like namespace updates, Adobe Catalyst (a tool for designers), unit testing, debugging, and a lot more.

Of particular note, Rose says, is that Flex 4 provides developers with better tools for working with data and services—in other words, data-centric development tools.  Flash Builder uses introspection on existing services to get a handle on things, creating models and wrappers on the client.

Those who are new to Flex in general will find the second part of the article to be of primary interest.  There, Rose invites his readers to join him and “get our hands dirty,” creating a Flex application in Flash Builder 4 that accesses data in a MySQL database using PHP.  You likely won’t learn anything new about MySQL or PHP, but you will get an idea on how Flash Builder 4 makes it almost trivially easy to write a Flex application, even when you don’t have the PHP already written…since Flash Builder 4 can actually write a PHP class for you to connect to the data.

This article makes for a great introduction to Flash Builder 4 and Flex in general.  You can download Adobe Flash Builder 4 from Adobe’s Web site if you’d like to get your feet wet with Flex.

In his rebuttal, John is quite matter of fact in his assertion that Adobe is not blocking HTML5. Additionally, he calls into question the editorial due diligence of AppleInsider and the author of the blog post, Prince McLean.

John quotes extensively from a statement by Adobe representative Larry Masinter’s comment on the subject.

I have many friends who hate Flash, refuse to install it on any computer they have (no matter how compelling the content) and anxiously await HTML5 because they see it as a Flash killer. Each time this conversation comes up, I like to remind them that Flash itself is not a bad thing, it’s the over-use of Flash by Marketing departments worldwide for such things as “Punch the Monkey” or the abomination of the web, sIRF, that are what is wrong, not the technology itself. Don’t think for a moment that these will go away because HTML5 is released—at best, they will just be updated and ported to the new technology.

Flash helped the web grow into new areas and, while we are all happy to see HTML5 come along, let’s not kick Flash (or Adobe)—instead, let’s remember that it served, and continues to serve, an important function.

All corporations, regardless of their corporate motto, have the potential to be evil and I don’t deny that Adobe shares in that potential. That having been said, Adobe has never seemed to me to be the evil type. I’m going to have to support John on this one and accept that, as he puts it, AppleInsider’s article may have been processed through the digestive system of a cow.

Disclaimer: Adobe is a client of Marco Tabini & Associates (php|architect’s parent company) and Blue Parabola.