Simon Horwith's Blog - Flex

A Few Thoughts About Various Programming Languages

Tue, 11 May 2010 17:40:00 -0400

In my role leading development shops, I am constantly having to learn and evaluate new programming languages and tools in order to keep us current as well as in order to discover better ways to accomplish goals. As a developer, I am also constantly learning simply because I want to get better at what I do, I love what I do, and learning new languages is a fun and rewarding undertaking. From time to time, someone writes a blog entry or gives a conference presentation about the importance of knowing more than one language... of not being a 'one trick pony'. I was reading Sean Corfield's recent blog post about Clojure and realized that I've never written about my recommendations or opinions of various languages that I've used or evaluated... until now. In no particular order, here are several of the technologies that I know and my thoughts about them:

Python
- I've recently been spending a decent amount of time learning and using Python - it's very fast and powerful, and is syntactically one of the most concise and elegant languages I've ever seen... it's VERY readable and the more I use it, the more I like it. Python is definitely one of my favorite languages.
Java
- I've used Java off and on since 1995, and somehow keep ending-up having to use it on projects from time to time. The language has gotten larger, faster, and for the most part, better over the past decade and a half - I found the language improvements in Java 5 particularly useful in that they clearly tried to make it easier to do what you want in your code. That said, I don't find Java programming particularly clever or challenging and on many projects I see, deployment is a terribly painful process. Java applications tend to have ridiculous file/directory structures and I'm not a huge fan of how strict it is. Java is everywhere and does have a huge job market, so it's worth knowing for those reasons... but it would never be my first choice of languages to use based on any merits other than the large talent pool and number of open source projects.
PowerShell
- Powershell is probably the coolest new thing I've seen in a long time. For those of you unfamiliar with it - it's a fully OO scripting environment for Windows (runs on .NET) and is free from Microsoft. The syntax is slick and simple, and the power you can pack into a single line of code makes it a no-brainer for anyone who needs or wants to administer a Windows network or machine. With powershell, windows finally has a shell that's better and more powerful than those available on nix systems. Bottom line: if you use Windows you REALLY should learn Powershell.
PHP
- PHP is yet another free technology - we use PHP and CF for most of our projects, and I like PHP a lot. A long time ago, some people called PHP "poor man's ColdFusion"... well, I think it's more true today than it was back then. It's simple, lightweight, and fast... and development times really aren't much longer than with CFML provided you're not trying to do something that CF does out of the box that there's no PHP module to do. I don't see it having many advantages over CF aside from price, the huge talent pool, and the number of open source projects. There's a good job market for PHP but those jobs don't typically pay as well, so I'd learn it because of it's popularity but I wouldn't choose a career focused exclusively on it.
Flex/ActionScript
- I've used Flex since beta 1, and I enjoy seeing how it evolves with each new release. I don't particularly like programming with ActionScript for the same reasons I don't like Java - but unlike Java, I do love the end result you get with Flex... enough to want to do it. No technology to date that's tried to compete with Flash has been compelling enough to use in lieu. There's also a great job market for Flex - especially here in New York City, and it's one of the top 3 or 4 technologies I'd recommend learning to anyone who wants a successful web development career right now.
ColdFusion
- I've used CF since the beginning and continue to use it heavily. It's not the best performing technology available but it performs well enough for most needs. No, it's not free, but development/debugging time is rapid enough to easily justify the cost. These days, CF's closed architecture and code base is a real turn-off for me personally, but it's the lack of talent (and the poor quality of most "talent") that is it's only solid turn-off from a business perspective. The native support for Flex is probably its most compelling unique feature... that, and it's rapid development nature. It's a good choice when you want a very robust user-friendly platform in a turn-key solution.
LISP
- LISP is, hands down, personally my favorite language. Five or six years ago I set-out to spend 6 months of my free time teaching myself LISP, and I enjoyed it so much that I just never stopped. The syntax took a little getting used to, and emacs takes even longer to get used to - which is probably the most annoying part of learning LISP (I haven't found a better free IDE for LISP yet). LISP is beautiful in the simplicity of its design - most notably in the interchangeable nature of code and data. It is definitely the most expressive and flexible language I've used - as well as the most powerful. Be warned; it takes a while to un-train yourself and learn how to really harness the power of LISP (particularly of macros and, if you're new to it, thinking in functional terms). I also, surprisingly, find the implementation of OOP in LISP (CLOS) much nicer and cleaner than that of any other language. I strongly recommend learning LISP. Not because there's a huge job market for it (there isn't) but because it puts other languages into perspective and because it WILL make you a better developer (I've learned more from 'tinkering' with LISP than any other language).

So, those are the main languages I've played with and developed feelings for recently (within the past 2 years). It's worth noting that there are other languages I left off for brevity. I've also been getting back into JavaScript these days - I have a new appreciation for it's functional nature and closures, and I think JQuery is pretty slick. I've taken a pretty good look at Objective C - it's a decent language but not worth learning unless you want to do a lot of Apple development. I've also played around with Clojure - which is essentially a pseudo-LISP implementation for the JVM - I liked it, but prefer to use 'pure' LISP... though it's attractive being able to write LISPy code that I can run on a JVM, since Java is everywhere. There are a few other languages I haven't had time to take a good enough look at yet but hope to very soon. Specifically, I'm interested in looking at Scala and Caml... and I've begun learning some Haskell and hope to dig into that a little deeper.

Apple vs. Adobe

Fri, 09 Apr 2010 14:43:00 -0400

Apple Wins :(
http://www.googlefight.com/index.php?lang=en_GB&word1=Adobe&word2=Apple
Yes, that really is all I'm going to say about the current Apple/Adobe war... except for a big shout out to Lee Brimelow for speaking his mind (http://theflashblog.com/?p=1888).
Right on, Lee!

Flex Camp Wall Street in New York Next Week

Fri, 13 Nov 2009 12:34:00 -0400

If you're a Flex developer in New York and don't know about it yet, there's a 2 day Flex Conference called 'Flex Camp Wall Street' (http://flexcampwallstreet.com/) on November 16 and 17 that at $49 to attend, looks like a great deal for attendees (what else can you do in New York for less than $50??)

I'll be presenting on ColdFusion/Flex integration at the conference on Monday.

Figleaf Takes Adobe Training Online

Fri, 23 Oct 2009 10:16:00 -0400

Fig Leaf Software (http://www.figleaf.com, an award winning Adobe Training Partner, is taking their training online - they're offering free training via the web for several Adobe products. Nice job, guys!
You can register and find out more at: http://training.figleaf.com/tutorials/

Is Adobe the Next Microsoft?

Thu, 06 Aug 2009 12:02:00 -0400

Adobe could be the next Microsoft... and that's not necessarily a compliment. Today, ZDNet News published an article titled "Is Adobe the next (pre-2002) Microsoft?" in which they compare the rising number of security holes being found and exploited in Adobe Flash Player and Adobe Acrobat Reader with the problem Microsoft had with vulnerabilities being exploited in their products years ago. It was so bad that among many circles, suggesting Microsoft products as a solution to whatever requirements you needed to meet was grounds for public humiliation. Their products were known targets and it was understood by many that using certain MS software was risky. No software is really 100% safe, but Microsoft took it seriously and became very proactive about addressing the (technical and image) issue both internally before software is released and publicly when a vulnerability is found. The article does give Adobe credit for being proactive and doing a reasonable job addressing vulnerabilities when they're found, but doesn't hide an opinion that Adobe still has a way to go.

The ZDNet article is online at http://news.zdnet.com/2100-9595_22-329118.html

Joint Meeting Between NY CFUG and NYFLEX UG Tomorrow Night!

Tue, 09 Jun 2009 18:04:00 -0400

For the benefit of anyone in NY who hasn't seen the email blasts, the NY Flex User Group and the NY ColdFusion User Group are holding a joint meeting tomorrow night (Wed. Jun 10th, 2009 at 6:30) for the Adobe User Group Tour. Ben Forta will be present for half the night on Centaur (ColdFusion 9) and Bolt (the new CF IDE) and for half the night on Flash Builder 4 (Flex 4). Should be a great evening.

The meeting is at:
New York Medical Center
550 1st Ave., Corner of E. 31st Street.
in the Smilow Seminar Room

Hope to see many of you there!

Nylon Technology is Currently Hiring in New York

Wed, 20 May 2009 13:46:00 -0400

Despite what they say about the economy, Nylon Technology has a pretty stacked pipeline and is going through a growth stage. I'm looking for Flex developers primarily, but we also have demand for ColdFusion and PHP experience. We're open to contract and full-time arrangements but candidates must be able to work on site in New York. If you, or anyone you know, is interested, email me your resume, availability, type of work you're looking for, and rate/salary requirements at shorwith@nylontechnology.com.

FigLeaf Cancels Top Gun Conference

Thu, 14 May 2009 17:59:00 -0400

FigLeaf has cancelled their scheduled top gun conference (http://training.figleaf.com/topgun/). From the conference homepage:
"Unfortunately we were not able to meet our attendance quota.
We'll be announcing other exciting training events, however, in July 2009."

ColdFusion Architecture For RIAs - Part 4

Thu, 07 May 2009 14:41:00 -0400

This is the fourth (and last) entry in a series of blog posts I'm writing to demonstrate ColdFusion in a RIA architecture. In the first entry, I introduced the simple CF version of an address book application. In the second, we looked at how to use the built-in CF 8 features to create a version of that application that uses AJAX to improve user experience. The third installment illustrated how a Flex application could be used to leverage the existing ColdFusion application logic while delivering a user experience that is far superior to what you can easily do with HTML and JavaScript. In this last installment, I am going to show how, with a few modifications to my lovely Flex UI and a little mapping on the server, I can use my existing CF application as the model provider for LiveCycle Data Services, and take my Flex application to the next level.

We'll begin by talking about what changed on the client. For the most part, the code is the same. One change is that I'm now getting my data from a DataService tag (rather than a RemoteObject tag) - this tells Flex to talk to my LCDS data service to get data. I disabled autocommit in the DataService - if I didn't, edits to grid rows would be automatically committed on the server for me with no additional work on my part. I turned it off in order to show how you can manually handle commits. Beneath the grid are buttons to commit or rollback all of the changes you make in the grid - each button simply calls a method on the dataservice (appropriately named "commit()" and "revertChanges()"). That's right - commit/rollback functionality without writing any actual code - nice!. What's nicer is that now I can open multiple clients and browse the application, and changes made by one client immediately reflect in the grid for all other clients, and if I try to edit a grid row that another client edits at the same time, it handles that conflict for me, too - no additional client code required. Wow... thank you, DataServices! There are two other small changes in the client code. First, to initially populate the grid using a DataService, you actually tell the dataservice to "fill()" the ArrayCollection you want to populate (again - this is simpler than handling a Remote Object result event). The other change worth noting is that I added the [Managed] MetaData tag to the DTO - this tells Flex that LCDS is managing these objects on the server for me (yes, you still also leave in the [RemoteClass] directive for mapping data types, too). OK, so the client is even more robust, and was made so with less effort. Surely, this must mean I did more work on the server? Let's see.

The 4 ColdFusion Components from the first version of the application are all still intact in the LCDS version - and none of the 4 were changed in any way yet again. Again, I have added a 5th CFC, 'facade.cfc'... only my facade cfc contains a lot more code than the facade for my 'simple' Flex version. This is because in order for LCDS to expose all of that cool functionality to Flex - the ability to retrieve all of the objects, add/edit objects, handle conflicts, paginate, etc. - you must in turn expose this same functionality to LCDS from your server side application (my facade.cfc in this case). The two questions you may be asking are "What methods do you have to expose to LCDS?" and "How does LCDS know what methods to call and what to pass them?".

First, LCDS. LiveCycle Data Services works by passing requests to a user defined "destination" - remoting in CF works this way, too. A default CF installation has a "ColdFusion" destination defined in it's remoting services XML file which points at the CF Server root (so you can call any CFCs on the server) - in the case of LCDS we add a destination to our data-management-config.xml file. The LCDS destination contains a lot more information than a typical remoting destination, though. If you're using CF as the data provider, you want to specify the "coldfusion-dao" adapter for your destination (make sure you've enabled it first) and define the communication channels - for real time it's "cf-dataservice-rtmp" and for polling it's "cf-polling-amf". You then specify the component that the destination will use - in my case it's the full package name to my facade CFC. You have to specify, in a 'metadata/identity' node of the destination, the name of the property in your CFCs that is the unique identifier - this is used by LCDS for edits, conflict handling, etc. You also have a few properties you can define for the fill method (the method that gets all records) and there are other properties of the destination you can define, but for the most part, that's all you have to do. When you write Java code to talk to LCDS, in the destination you can specify the names of all the various methods to call (as well as some properties of those methods) but in the case of CF, LCDS is hard-wired to use reserve method names on the CFC you specified. So there's really very little to do to configure LCDS for CF. All the "work", as I suggested earlier, is in the component you point your destination at... so let's take a look at what I did in facade.cfc.

As I said, all of the original CFCs were left in tact - we need only expose the right functionality and data to LCDS from one CFC (facade) using reserve method names - that facade (often refered to as an Assembler) talks to my other CFCs. One thing to note is that LCDS will pass a change object (or an array of change objects) to many of these methods. That change object has methods to tell you if this is an add, edit, or delete, and has methods for getting the old data and the new data (the old and new DTOs). The methods LCDS expects and a brief description of each are as follows:

fill

Returns all entries as an array of DTOs

get

Gets one DTO - receives a structure containing the unique id of the DTO to return

sync

Sync accepts an array of change objects - for each one, the sync method passes the change object to the appropriate action method (add/edit/delete method). Those 'action' methods return the new DTO (or old if there's a conflict or some business rule failure) which is placed in an array that the sync method ultimately returns.

count

Tells LCDS how many DTOs there are.

create

Receives a change object, creates the new DTO, adds that to the newVersion property of the change object, marks the change object as 'processed', and then returns the change object

update

Receives a change object and compares it's old DTO with the matching live DTO to make sure there isn't a conflict (resulting from trying to edit a DTO that another client already edited) - if there is, it flags the conflict in the change object. If there isn't, it commits, adds the new DTO to the change object, and returns it.

delete

Receives a change object and checks to see if that DTO was already deleted (in which case it flags the change object as 'failed'). If it wasnt, the method performs the delete, adds the deleted ID to the change object to flag it as deleted to all other clients, and marks the change object as processed.

All of this might seem like a lot of work, but if you download the code (http://www.horwith.com/downloads/abook-lcds.zip) and take a look at the facade, you'll see that it's actually fairly simple to implement - especially given the functionality it allows you to drop-in to your Flex/LCDS applications. That zip file also includes the Flex LCDS code, and the config file for my LCDS server destination. If you're comfortable working with CF, using it as a provider to LCDS allows you to build very rich clients in Flex without having to struggle with client code. You could, of course, use this facade to introduce many of the same features to "regular" CF applications as well.

I hope these past 4 blog entries were useful for folks. Here are the links to the various versions of the code:
Regular CF Version
CF AJAX Version
Flex Version
LCDS Version

ColdFusion Architecture For RIAs - Part 3

Thu, 07 May 2009 14:36:00 -0400

This is the third of a series of four blog entries I'm writing to demonstrate CF in a RIA architecture. In the first entry, I introduced the simple CF version of an address book application. In the second, we looked at how to use the built-in CF 8 features to create a version of that application that uses AJAX to improve user experience. Although in order to create a better user experience in each version of the application I'm writing a good deal of client code, the purpose of this exercise is to examine how much refactoring/effort is needed on the server-side to support the UI changes. In this, the third installment, I am now going to replace the CF driven HTML front-end with a Flex application.

Note, I was a little lazy and kept the code and the runtime files in the default Flex Builder directory structure. As with the AJAX version, for this version of our address book application we have two objectives: re-use what we can from the first version of the code (http://www.horwith.com/downloads/abook-cf.zip) and offer some RIA benefits/characteristics by using Flex for the front end. You can download this code at http://www.horwith.com/downloads/abook-flex.zip. To test, first extract the zip file to a web root served by ColdFusion. If you haven't run the first version of the application on your server yet, you'll want to download and follow the instructions for that application in order to configure your database and datasource. You can browse the application simply by browsing the "bin-debug/main.html" file in the "abook-flex" directory created when you unzipped the compressed file, though depending on how your environment is set-up you may need to recompile the source. The interface is now extremely different (duh, it's Flex, not HTML). The A-Z links are now A-Z buttons (I could have taken a "prettier" approach but this suffices for my needs) and there's a 'show all' button. Like I said, buttons aren't the pretties way to do this in Flex (nor the fastest, in all likelihood) - I just threw them in there like that real fast. The address book entries are all displayed in a pretty data grid. I could have easily paginated it but don't mind the default scrollbar behavior for data sets this small. You can edit entries inline in the data grid, but I didn't take the time to add delete or 'add new' functionality, though it wouldn't be much effort to do so. You may notice (though in an app. this small you also may not) that the data loads a little quicker than it did with the AJAX/HTML versions. That's largely due to the fact that Flex is smart (and sneaky) about when it draws things, and partly due to the performance benefits you get out of the box by using AMF (Flash Remoting) to talk with CF. Definitely a nicer interface.

So how did the server side code need to be modified? First let's look at the old server (CF/AJAX) UI. For starters, all of the '.cfm' files are gone - replaced with a single '.mxml' file that is our application. This file has a datagrid, populated when the app initializes, for displaying all of the entries, and functions for asking the server for the entries, adding a new, empty row (add), handling edits, and for filtering the displayed entries. Basically - it's a grid populated by an ArrayCollection, with a few UI elements and some functions for passing elements of the ArrayCollection back to the server. There's also a class (a data transfer object in the 'dto' directory) that represents an address book entry - the ArrayCollection is actually an array of these. Note that the DTO class file has a [RemoteClass] metatag - this maps my server-side addressbookentry object to the AddressBookEntry AS class so my custom object types translate seamlessly back and forth. Sorting and filtering is more efficient than in the prior 2 versions of this application, as Flex has native support for filtering and sorting content on the client.

The 4 ColdFusion Components from the first version of the application are all still intact in the Flex version - and none of the 4 were changed in any way yet again. What has changed is the addition of a 5th CFC, 'facade.cfc', which is a simple implementation of the facade pattern. Like the facade in the AJAX version, this CFC accesses the user's address book the simplest way possible - by directly referencing the session scope. There are only 2 methods (and barely any code) in the component - one method for retrieving all entries and one for adding/editting an entry. Though I haven't been as diligent in trying to optimize both approaches as I possibly should be, in my opinion integrating a Flex UI with CF is much simpler and more straight forward than with an AJAX front end.

Though this Flex application really doesn't do Flex justice in terms of it's capabilities, it does do a decent job reflecting how much more robust the interface can be and how much simpler it is to integrate ColdFusion with a rich client written with Flex.

ColdFusion Architecture For RIAs - Part 2

Thu, 07 May 2009 14:34:00 -0400

This is the second of a series of four blog entries I'm writing to demonstrate CF in a RIA architecture. In the first entry, I introduced the simple CF version of an address book application. In this installment, we'll examine what changes need to be made to that code base in order to make it work using an AJAX client.

I'll begin by stating that, to keep with the Adobe technology theme, the AJAX functionality that ships built-in to CF 8 was chosen. These CF AJAX server enhancements were fairly well received by the CF developer community and from what I can tell were very well received by Adobe's CF clients, and I don't think anyone was surprised to see AJAX support added to the server. That said, my personal experience with the CF 8 AJAX functionality so far has left a bad taste in my mouth - at least with regards to the tags that generate an AJAX UI. As soon as you need to make them do something that isn't natively supported via the tag attributes, developers find themselves banging their head against the wall. It's that same old "trying to fit a square peg into a round hole" feeling that I run into from time to time with frameworks, CMS products, and even CFML itself on some occasions. There are a lot of excellent AJAX libraries out there and in my experience developers are often times better off downloading, learning, and using one of those... but I digress.

For this version of our address book application we have two objectives: re-use what we can from the first version of the code (http://www.horwith.com/downloads/abook-cf.zip) and offer some RIA benefits/characteristics by taking advantage of ColdFusion AJAX support. You can download this code at http://www.horwith.com/downloads/abook-ajax.zip. To test, first extract the zip file to a web root served by ColdFusion. If you haven't run the first version of the application on your server yet, you'll want to download and follow the instructions for that application in order to configure your database and datasource. You can browse the application simply by browsing the "index.cfm" file in the "abook-ajax" directory created when you unzipped the compressed file. You'll notice a few differences in the interface. The address book entries are all displayed in a pretty JavaScript grid. The entries are paginated for you, with nice navigation controls for moving around the pages... moving from page to page does not require refreshing the page in your browser. The A-Z links are still there, and work as before, but again we no longer refresh the page. The "Add Entry" button now displays a virtual window with a form, that you can submit, drag around, or close. Also, the "Edit" links have vanished - you can edit records directly inside the grid that displays them. Definitely a nicer interface.

So how did the code need to be modified? First let's look at the UI. For starters, the 'entry.cfm' file from the first version has been deleted and the form moved into a CFWINDOW in index.cfm for in-line use. Index.cfm has an ajaxproxy at the top, so we can communicate with the server from JS. The HTML table has been replaced with a CFGRID which gets it's data via the 'bind' attribute. Several JavaScript functions, all which very simple, were added to the page - primarily for refreshing the grid (via methods of the ColdFusion.Grid object) and for interacting with the add entry window (via methods of the ColdFusion.Window object). At the bottom of the page, the CF8 ajaxOnLoad() function is called to populate the grid when the page loads.

The 4 ColdFusion Components from the first version of the application are all still required for the AJAX version - and none of the 4 were changed in any way. What has changed is the addition of a 5th CFC, 'addressbookintrepretor.cfc', which is a simple implementation of the facade pattern. This CFC accesses the user's address book the simplest way possible - by directly referencing the session scope. Not a practice I generally encourage, but acceptable in a facade. There are 5 remote methods in the component - 3 of which just accept data and pass it to the address book (for deleting, adding, and editting entries). There's one entry that simply returns the current entry count (based on a filter) since the AJAX UI can no longer just reference the recordcount of whatever query is being displayed. The fifth method is the getEntries method which is used to populate (and re-populate when filtering) the data grid. This is the only method that actually has any AJAX-specific code in it - it takes the array of objects, converts it to a query, then returns the result of operating on that query with the CF 8 'queryConvertForGrid()' function.

The interface is inherentely a little prettier and the user experience is definitely more pleasant. If you've never used the CF AJAX functionality before, it takes a little while to add the code needed for this version - and if you don't know JavaScript at all it will take even longer... but for an application this simple anyone should be able to do what I did in a few hours (anywhere from 2-6 hours) with little prior experience. Were the enhancements worth the extra time? I don't really know, you tell me. What I will say is that since I'd written all the server side code and a simple HTML version already, I thought it was realistic to expect that I'd have time to add a nice interface for deleting gridrows and to write code to elegantly handle making the grid refresh and resort whenever I clicked on a header or add/edit/delete entries. Clickable headers alone is trivial, but as soon as you throw all the CRUD functionality into the mix, the amount of effort required increases to a number that, in my opinion, isn't worth it.

ColdFusion Architecture For RIAs - Part 1

Thu, 07 May 2009 14:28:00 -0400

This is the first of a series of four blog entries I'm writing to demonstrate CF in a RIA architecture. Each entry will take a "plain" ColdFusion application and show how it was necessary (or not) to modify the code to handle the requirements of a "Web 2.0" application. This first entry is an overview of traditional vs. next-gen web applications and is an introduction to the "plain" CF application that will be the starting point for the other three "Web 2.0" applications I describe in the next three posts.

The necessity to deploy Rich Internet (or "Web 2.0") Applications is a fact of life these days. They often deliver better ROI and competitive advantage, and today's web citizens expect and sometimes even demand a better user experience. The flash platform is, at least without a doubt in my mind, the ideal platform for delivering these applications. Some companies and developers prefer to use AJAX - and if it does what they want then that's fine for them. I'm not writing to debate the merits of one technology versus another (not today, anyway). What I want to write about is the impact that this has on the architecture of a typical ColdFusion application.

On several occasions in the past years I've written about the role of CF, in the context of next generaion web apps, changing from that of a "presentation server" that is also capable of performing business logic to that of a "service provider". For the most part this is true in the case of "Web 2.0" applications - except for those scenarios where CF is generating the RIA presentation layer (i.e. CF is creating the code for an AJAX front-end using the new CF8 CF-AJAX tags or is dynamically generating other AJAX or possibly Flex interfaces). Even then, though filling the role of presentation server, let's assume for argument's sake that CF is also filling the role of service provider. So how does all this impact the architecture of your CF application?

We'll start with a very simple address book application written entirely in CF. You can download this code at http://www.horwith.com/downloads/abook-cf.zip. To test, first extract the zip file to a web root served by ColdFusion. To set-up the application as-is, run the "create-sql-server-db.sql" file against a SQL Server 2005 database, then run "create-db-tabls.sql" against that database... create a datasource in the CF Admin named "abook" that points to the new database, then browse "populate-db.cfm" to populate your new database. All of the database related files are in the "build-db" directory created when you unzip the zip file. You can browse the application simply by browsing the "index.cfm" file in the "abook-cf" directory created when you unzipped the compressed file. There's nothing "Web 2.0" about it. There's a .cfm that shows all the entries in our address book, with links to filter by first letter of last name and links to edit records, and there's a .cfm that displays a form for adding and editting address book entries. There are also 4 ColdFusion Components, which are the "meat" of the application:

addressbook.cfc - represents an address book
addressbookentry.cfc - a data transfer object (DTO) representing an address book entry
addressbookdao.cfc - the parent class of all address book Data Access Objects (DAOs)
addressbookmssqldao.cfc - the address book DAO containing all the CRUD methods for SQL Server

Not only is there nothing "Web 2.0" about this code, but I should also state for the record that I had no intent of using it in a "Web 2.0" environment. It was actually written as part of an object orientation code exercise I conducted at Nylon Technology. This fact only makes it an ideal candidate for use in illustrating the impact of leveraging "legacy" code in next-generation applications. All of the data is cached in the session scope - the idea being that when a user logs-in, their address book(s) are loaded into the session scope and synchronization with the database actually happens behind the scenes. It's worth mentioning that to keep things simple I've taken 2 shortcuts. First, there's no actual log-in... in the real world you'd force a log-in and, at that time, select the address book IDs for all the address books owned by the current user. Second, since there's no log-in, the code is hard-wired to assume that for any request the address book ID from the database is 1. You can see this defined in the Application.cfc "onSessionStart" method.

Registration is now open for the FigLeaf 'Top Gun Conference'

Fri, 27 Mar 2009 16:21:00 -0400

Once upon a time, the very talented folks at FigLeaf Software offered 'Top Gun' Training. In recent history, they began an annual 'Flex Maniacs' conference which became the 'Web Maniacs' conference. This year they've resurrected the 'Top Gun' naming and re-branded the conference as the 'CF & Flex Top Gun Conference', which is actually 3 one day conferences back to back. Day 1 is CF and AIR, day 2 is CF and Flex for Newbies, and day 3 is Flex and AIR.

Registration is now open - you can get one day passes for $199 or a 3 day pass for $499. Registration is online at https://training.figleaf.com/topgun/registration/index.cfm.

These days I'm very selective about what conferences I endorse and even more selective about which conferences I'll attend. I'm happy to say that I will be attending and speaking at the top gun conference, as I feel that of all the conferences this year, it's the best deal out there for the developers.

Flight of the Conchords (and more)... streaming to a Flash Player near you

Tue, 03 Mar 2009 15:13:00 -0400

Adobe and Time Warner announced a strategic partnership yesterday (http://news.cnet.com/8301-17939_109-10186110-2.html) which included the announcement that HBO will be relaunching their site with heavy use of Flash.

Sweet.

Zend Releases PHP Application Server

Thu, 19 Feb 2009 12:18:00 -0400

Zend released a PHP Application Server beta today called "Zend Server" - http://www.zend.com/en/products/server/. It looks interesting, especially given the recent addition of AMF support to the Zend framework. I hope to find time to "play" with it in the very near future and, when I do, will post about my thoughts and experiences with the product. I'd also be curious to hear what experiences other people have with it.

How does this affect ColdFusion? To be honest, I won't be surprised to see some companies decide to use the Zend Server instead of CF - simply because it's PHP (not to say that there aren't some benefits inherent in that fact). That said, I don't see it as a technical competitor to ColdFusion because the decision to use one application server over another should be based on the features of that platform - the Zend Application Server appears to be a vanilla server out of the box whereas CF is integrated with dozens of features. Having support for these same features on the Zend Server would require writing or downloading the PHP code necessary for that functionality and then integrating it into the server environment. Of course, business decisions about software and programming languages aren't always based entirely on 100% sound technical merit.

If you're in the New York area, next month Ricky Robinett will be giving a presentation on Flex integration with the Zend Application Server at the New York Flex User Group (http://www.nyflex.org).