Jun 19, 2009 . Comments (2)
And this is why I like Coldfusion so much. I have been a huge fan of Coldfusion for many years. The tagging structure and relatively few lines of code required to do some rather complex things are a huge win for me. Integrating Coldfusion to Flash and Flex has always been relatively painless, especially with remoting, however the guys at Adobe are about to blow the roof off with how simple server integration from Flex can be.
<cf:Mail id="cfMail"
to="{to.text}"
from="{from.text}"
subject="{subject.text}"
content="{body.text}"
type="html" />
That's a sample in MXML, not Coldfusion, holy flying centaur's batman!
Here's a quote from Ben Forta's site.
And while we're at it, what about the Flex developer who needs to generate an e-mail message? Flex (well, Flash) has no built in SMTP libraries, and so Flex developers who need to programmatically generate e-mail messages do so by writing code on the server. For ColdFusion developers this means creating a ColdFusion Component which accepts data from a Flex application (likely via an AMF call) and then passes that same data to a tag. In other words, code is being written on the server just to be able to pass data from Flex on the client to the tag. So why couldn't a Flex developer just invoke directly, passing it name=value pairs so it can generate an e-mail?
Well, with the upcoming ColdFusion Centaur, the answer to all of these questions is yes, these are all doable! In ColdFusion Centaur we're exposing lots of those integrated ColdFusion services via AMF (Flash Remoting) and SOAP (Web Services).
You can read the full post here. There is also a great vid with Ryan Stewart on Adobe TV showing how to use the Coldfusion tags Ben mentions, talk about sweeeet.
I can not wait to get my hands on Coldfusion 9 and the full list of exposed services.
Jun 12, 2009 . Comments (4)
On a few recent projects I have needed to access various server side functions including database records and files from Flash. The server environment dictated that PHP would be the server side language to use. I'm sure many of you have integrated Flash/Flex with PHP, it's pretty easy to do. Create a PHP file, have it echo out some text. In Flash use a URLLoader to pass down any variables and then load the resulting data. That method has been around since Flash 5/6, pretty bullet proof.
What I wanted to do on the server side was setup something that was a little more robust and service oriented. Instead of having to create a separate PHP file for each server function I wanted a single point of entry to the server and a simple interface for sending and receiving data, something more akin to RPC or REST.
The other criteria was that I wanted something super lightweight. I could have used AMF on the server, either WebOrb PHP or AMFPHP. I have used both and they work great, however in this case the amount of data being sent back and forth would not really benefit from AMF and I didn't want the headaches of trying to get the server admin to approve setting it up on the server (which really isn't a huge deal).
What I came up with is a single PHP class that acts as the API. It accepts incoming calls, checks the variables, handles any errors, and returns the data (or any faults) in a simple, structured format. Let's walk through the PHP first and then we can deal with how to consume it from Flash or Flex.
The first step is to create a file called Api.php and then setup a function to catch any php exceptions so that we can correctly deal with them and send a structured response to the client instead of some cryptic PHP error message. One thing to note in the code is that this does not work for errors thrown from the mysql functions, or other db functions for that matter. We need to do something special in the mysql calls, but I'll get to that later.
//function for catching php excpetions
//this won't work with mysql calls so we need to catch
//mysql errors and rethrow the error
function exception_error_handler($errno, $errstr, $errfile, $errline )
{
throw new ErrorException($errstr, 0, $errno, $errfile, $errline);
}
set_error_handler("exception_error_handler");
Now we get into the meat of the solution, the Api class. The constructor essentially consists of two pieces. A switch statement to deal with each method that can be called and then echoing out whatever the response from said method is. The whole thing is wrapped in a try/catch so we can deal with any errors that crop up.
class Api
{
private $eol = "
";
function __construct()
{
try
{
switch ($_REQUEST['method'])
{
case 'helloWorld':
$response = $this->helloWorld();
break;
case 'addValues':
$response = $this->addValues($_REQUEST['value1'], $_REQUEST['value2']);
break;
case 'getRecords':
$response = $this->getRecords();
break;
default:
$response = new Response();
$response->status = "error";
$response->data = '<![CDATA[Method does not exist]]>';
break;
}
}
catch (Exception $e)
{
$response = new Response();
$response->status = "error";
$response->code = -1;
}
echo $response->toXmlString();
}
}
The next piece is creating the Response class. This class gets used to return any data or exceptions to the client. It provides a simple xml structure that can be easily read by actionscript. The benefit of using something structured like xml is you can easily deal with any type of returned data, it's flexible, and you have a nice standardized format for communicating between the server and client.
class Response
{
public $status = "ok";
public $code = 0;
public $data = "";
private $eol = "
";
public function toXmlString()
{
$response = '<result status="' . $this->status .'" code="' . $this->code .'">' . $this->eol;
$response .= $this->data . $this->eol;
$response .= '</result>';
return $response;
}
}
As you can see, it's a pretty simple little class. Three properties and one function. The status can be set to either 'ok' or 'error' for my purposes. The code is any particular error code I want to return to the client. I can use the code on the client side to look up any particular error message I may want to display, separate from whatever the server returns. Finally, the data property which will contain any output from the called method. The toXmlString method is called from the Api class constructor and it simply formats the Response class values in clean xml text that php can echo out.
That is the basic framework of the Api, the next step is filling in the methods. I have three samples to give an idea of what you can do. These two are really basic, a simple hello world and adding two values together. They simply show how the Response class is used to set the data to be returned.
private function helloWorld()
{
$response = new Response();
$response->data = '<![CDATA[Hello World]]>';
return $response;
}
private function addValues($v1, $v2)
{
$response = new Response();
$response->data = $v1 + $v2;
return $response;
}
The final method is a little more involved. It is reading records from a database and then returning the values. A few things to note. First, I use a conditional if statement to determine whether or not the mysql_query actually worked. If it returns false, then I purposely throw an Exception and then allow the try/catch and error handling we setup at the top deal with it. Second, I use the htmlspecialcharacters to escape any problem characters in the xml attributes. I could have used a CDATA to store the name but that tends to bloat the xml more than necessary, it's something totally dependent on the situation.
private function getRecords()
{
try
{
$query = "SELECT user_id, user FROM users LIMIT 0,5";
if ($result = mysql_query($query))
{
$response = new Response();
$response->data = "<users>" . $this->eol;
while ($row = mysql_fetch_assoc($result))
{
$response->data .= '<user id="' . $row['user_id'] . '" user="'. htmlspecialchars($row['user']) .'"/>' . $this->eol;
}
$response->data .= '</users>';
}
else
{
throw new Exception("mysql error", 0);
}
}
catch (Exception $e)
{
$response = new Response();
$response->status = "error";
$response->code = $e->getCode();
$response->data = '<![CDATA[' . $e->getMessage() .']]>';
}
return $response;
}
Next up, accessing the php class from Actionscript. I'll step through two different approaches, the Flash way and the Flex way. The Flash way would work in Flex, however with Flex you get a few little goodies for handling rpc that make it a little cleaner.
The Flash way. Use a URLLoader, very straight forward implementation here. Create an instance of the URLLoader and URLRequest classes. Point the URLRequest at the php file. Create an instance of the URLVariables class and set the properties you intend to pass down. The critical property is the method property which the switch statement on the php side uses to determine what to do. Finally, add a result handler and you are good to go.
private function addValues():void
{
var loader:URLLoader = new URLLoader();
var request:URLRequest = new URLRequest("http://local.test.com/api.php");
//add the required variables
var data:URLVariables = new URLVariables();
data.method = "addValues";
data.value1 = value1Txt.text;
data.value2 = value2Txt.text;
request.data = data;
loader.addEventListener(Event.COMPLETE, handleLoaderResult);
loader.addEventListener(IOErrorEvent.IO_ERROR, handleIOError);
loader.load(request);
}
The result handler is called after the php script echoes out the response. Here we grab the data from the loader, check the status attribute to make sure it's all good, and then display the result, or show the error message.
private function handleLoaderResult(event:Event):void
{
var loader:URLLoader = event.target as URLLoader;
var data:XML = new XML(loader.data);
if (data.@status == "ok")
{
Alert.show(data, "Result");
}
else
{
Alert.show("ERROR: [" + data.@code + "]" + data.toString(), "Error");
}
}
That's it for Flash, it's simply a matter of parsing the xml returned in the loader and then doing whatever you need with it.
And finally, the Flex version. The Flex framework includes a whole host of classes for working with RPC. For these purposes I'll use the HTTPService, AsyncToken and Responder. In the Flash version, you would need to create a URLLoader each time you wanted to call the php api. Flex simplifies this by allowing you to create an instance of the HTTPService class that can get reused. You can define the service in MXML, give it an id and point it at the url you wish to call. The other really nice thing is you can define what format the result will be returned in. For this sample I set it as e4x so I don't need to worry about parsing the data to xml when it comes back from the server.
<mx:HTTPService id="api" url="http://local.test.com/api.php" resultFormat="e4x"/>
Once the service is setup we can create the functions to use the service. A few differences from the Flash version. First we can simply access the instance of the HTTPService via the api variable. Second, we create an instance of the Responder class and add result and fault handlers to it. If the remote service executes correctly (or throws and handles an exception it has been coded to deal with) the result handler gets called. If something blows up, the fault handler gets used. In this sample I use the same result and fault handler for each call. In reality you would likely use different result handlers for each rpc call, in order to deal with the returned data in the correct fashion.
private function helloWorld():void
{
api.request.method = "helloWorld";
var token:AsyncToken = api.send();
var responder:mx.rpc.Responder = new mx.rpc.Responder(handleResult, handleFault);
token.addResponder(responder);
}
private function addValues():void
{
api.request.method = "addValues";
api.request.value1 = value1Txt.text;
api.request.value2 = value2Txt.text;
var token:AsyncToken = api.send();
var responder:mx.rpc.Responder = new mx.rpc.Responder(handleResult, handleFault);
token.addResponder(responder);
}
private function getUsers():void
{
api.request.method = "getRecords";
var token:AsyncToken = api.send();
var responder:mx.rpc.Responder = new mx.rpc.Responder(handleResult, handleFault);
token.addResponder(responder);
}
And here are the result and fault handlers. Again, very generic. The only thing of note, in the result hanlder, since we defined the result format for the service as e4x, we can directly access the event.result property as an XML instance without parsing it like we needed to in the Flash only version.
private function handleResult(event:ResultEvent):void
{
if (event.result.@status == "ok")
{
Alert.show(event.result, "Result");
}
else
{
Alert.show("ERROR: " + event.result.toString(), "Error");
}
}
private function handleFault(event:FaultEvent):void
{
Alert.show(event.fault.message, "Fault");
}
I hope you found this helpful, nothing like some PHP/Actionscript/XML talk to pep up the day. You can download the sample files here if you are interested.
Jun 08, 2009 . Comments (6)
I am always amazed at the number of times I speak with people who are looking for freelance Flex developers and end up having no luck finding a decent contractor or they have contracted with one and then gotten burned. Maybe I'm a little naive and think freelance contractors would have more scruples, apparently some don't. If you make a living providing services to companies and individuals what more valuable asset do you have then your reputation and your word? Ruin those and you are done ... protect them, guard them, do your best to enhance them and you should have little trouble finding and keeping clients and work.
Here are a few pointers to anyone looking for freelance Flex or Flash developers (or any web contractor in general for that matter).
- Always ask for references. Whenever I am in the position to hire or contract an individual or company I always asked for references. What better way to quickly evaluate if someone is what they say they are. A five minute conversation with a few past clients will quickly add clarity to the picture you form on someone's character and capabilities. Anytime I meet with a prospective client I'm prepared to provide references and I'm always astonished at the number of times they never ask. It boggles my mind that people don't check references.
- Check their website and blog. Two things I personally think of with my website are: 1. you only get one chance to make a first impression and 2. always dress the part for a job or business interview. I would consider a freelance developer's website an immediate litmus test on whether or not they are worthy of your business. Does it look professional and maintained? I know looks are subjective and everyone has different taste but you should be able to set taste aside and determine if something looks professional. Have they put effort into making the best impression they can? Do they have a portfolio or list of projects that reflect quality workmanship? If they have a blog, are they blogging on development related items? Do they provide any samples or demos you can look over to get a feel for their development skills?
- Put on your PI hat and Google them. Spend 10 to 20 minutes investigating their online presence. Google their name, their domain name and their email address. Look them up on LinkedIn. Find out the good, the bad and the ugly about them. Remember that not everything you find is 100% accurate but it should help to give you a good feel about the person. I worked at an interactive shop that hired a quote/unquote developer who looked great on paper. Turned out he was great at self promotion and not so great at development. Unfortunately the person who was responsible for hiring him didn't bother to do any research on the person. Five minutes on Google would have turned up multiple reasons not to hire the person.
- Are they a full-time freelance flex developer or a moonlighting developer? Those are two very different things. I have nothing against developers moonlighting, I've done it and you can find some people who moonlight and can be a great asset to a project. You need to realize a moonlighter can not devote the same energy to your project that a full-time contractor can. Are you comfortable with that? Do you have tight deadlines or need frequent contact during normal business hours? Even full-time contractors may not be able to devote full energy to a project. Ask a prospective contractor what their schedule is like. I'm open with my clients and potential clients about my schedule. If my plate is full I explain that up front so their expectations about my time can be managed and realistic.
I'm sure many people already follow similar ideas when evaluating developers and doing so is no guarantee you won't get a rotten apple, but hopefully they can reduce the chances of it happening to you.
If you are looking for a Flex or Flash contractor and don't know where to start feel free to contact me. I may not be available to help on your project but I can hopefully point you to some resources that may be able to.
Related Post:
Where to find Flex developers?
Jun 03, 2009 . Comments (0)
If you are up to date with Flash and Flex no doubt you have heard Flex 4 and Flash Builder (aka Flex Builder) have been released in beta. Great stuff, lots of new things to try out.
First thing I went looking for is the language reference. There is a whole slew of new 'spark' components which are, in some respects, a large departure from the mx (halo) components. The language reference will be a life saver in finding what's new, what's been added and more importantly what's been removed. As you scroll through the toc panel you'll notice a lot of the items are doubled up, that's because Adobe is providing the documentation for both the mx and spark versions of each component. You need to look closely at either the url before you click on the link or the package name after to make sure you've got the right one.
Second thing to find was the Flex 4 help guide. Adobe always does a decent job of providing details on the new architecture, components, etc. A lot of it is carryover from Flex 3 but there is some good info specific to spark: skinning, containers, and list controls.
Stay tuned as I start to dig into Flex 4, it's been a long journey from Flex 1 but it keeps getting better.
Jun 02, 2009 . Comments (1)
It seems like nothing can bring on a heated debate between developers faster than talking about frameworks. I have used Cairngorm for longer than I would like to admit, and for better and for worse it has served me well. Recently I started working on an AIR application that is based on Swiz. I had heard of Swiz, pretty sure I even wathced a video from a conference where it was demo'd. It sounded interesting at the time but once you are entrenched in one framework (and too busy to find the time to try out something new) it is difficult to entertain the idea of starting to use a new framework in your projects. Fortunately, taking on an existing project based on a framework new to you forces you to quickly get up to speed. In the case of Swiz, it didn't take long.
There's a decent getting started guide that steps through the basics of getting up and running with Swiz. Even better though is a five part series by Brian Kotek on using Swiz.
- Initial setup
- Dependency injection
- Events
- Dynamic responders
- Simulating server calls
Brian did a great job in covering the basics, providing some good examples and explaining in detail some key features in Swiz and how to use them.
Fortunately I have been able to get a good handle on Swiz in a short period of time. I'm looking forward to working with it in this current project and also in some future projects I have been planning out. Hopefully as time permits I'll even get a post or two up on how I find it.
