Digital Ninja

Quick post tonight, as I'm between tasks. I've been wanting for a long time to get more familiar with ExtJS, a most excellent JavaScript application framework (can I call it that?). It's the good stuff that's built into ColdFusion 8, but that was version 1.1. Since then they've gone all the way to 3.0, and the platform is getting better and even more expansive.

What I wanted to do was get into it, but I kept getting sidetracked. It can be a bit to digest in one sitting - or even 10. Eventually, I heard of ColdExt, which is a ColdFusion, er, helper application... well, it's like training wheels. I hope that doesn't offend anyone - particular the ColdExt gang. It's really amazing what they've done. Using their imported tags you can get off the ground really fast using the familiar tag-ness that is ColdFusion but when it's processed and sent to the browser it's all proper ExtJS JavaScript.

Now, I LOVE this. What it's doing is providing me, the developer, those all-important positive and productive feedbacks we call "success". In no time I had an AJAX-powered grid with a CRUD form hooked up to the rows. Even better is that some of the things I wasn't completely familiar with in the ExtJS syntax was getting written for me. A quick view-source and I was staring at a guide for how the under-hood-goods were written. This has helped me gain mountains of comfortability with this JavaScript framework!

So, even if you don't want to use ExtJS through a layer of ColdFusion tags in the end, I highly recommend you ease into the deep and incredibly powerful world of ExtJS via ColdExt. It put the "RAD" back into my AJAX/Rich Client applications. That's just awesome.

I think I found myself a solution. First, here's the problem.

The Problem

I have Transfer managing my ORM. It works awesome, I love it, and now I want to start building AJAX-based tools to manage the data through Transfer. But Transfer hides all properties of a class behind getter and setter methods, so when I hit a remote CFC to get, say, new("person") or get("person", 42), all that comes back in a JSON string is {}. No properties visible, so nothing comes back.

The Solution

My LTOFactory (Lightweight Transfer Object) is a component that will talk to Transfer, get the object I'm looking for, and then return the product of Transfer-ORM's built in getMemento() method, which is a simple struct that contains all the properties - publicly exposed. Now my JSON string has the properties!

The same concept for the get method can be, with a little elbow grease, made to work also for list, save, and delete if I choose. If I do that, LTOFactory probably isn't a very good name anymore, but I'm talking results here, not semantics.

The Code

Here is my LTOFactory code.

Here is my ColdSpring configuration that sets up Transfer, its factory, the LTOFactory with dependency injection, and the AOP remote bean configuration so I can hit the LTOFactory via AJAX.

I'm working awfully hard these days to be a lazy S.O.B. What I'm trying to do right now is figure out how I'm going to send and receive a simple JSON data chunk that represents a business object (a "data transfer object" (DTO), a.k.a. "value object" (VO) or just "transfer object" (TO)) to and from a remote proxy bean (CFC) generated by ColdSpring AOP. This is not hard to do. What's become an unexpected challenge, however, is when that remote proxy bean is a Transfer factory (from the awesome ORM framework by Mark Mandel).

If you don't know already, here is what will happen with a class pulled out of the Transfer factory when slurped down a remote access pipe; as a part of the process of translating it to a JSON string to send back to my AJAX call, ColdFusion will only turn public, visible properties in the ColdFusion component into JavaScript object properties. This doesn't serve me well because Transfer will not expose any data properties. Rather, it makes getter and setter methods for each property - which I love! But I don't love it for trying to bounce objects back and forth via AJAX/JSON.

All that I've said so far makes it difficult to receive object data without some custom service layer nonsense (I'm lazy, remember?) But just as frustrating is that there doesn't seem to be a simple way to pass an argument collection of property name-value pairs to a constructor in the Transfer factory to create a new object or update one. There is a get method which will return a new class of the requested type, but no way to send in a struct full of default values, which is what I would push up to the service layer via AJAX in my RIA.

Am I going to have to write a custom service layer after all this? I've been poking and prodding for hours here trying to avoid this work.ﾠ :) Yes, I fully appreciate the irony in this. I'm a geek, it's what I do.

I couldn't help it, I had to post on this topic even though it's kind of a hot topic and you'll find many other posts out there on this. Hot indeed, and yet I need to search around quite a bit for the answer to my error.

First, to follow me, here's some homework to read up on in case you're not down with Google's hosted AJAX API scripts and the google.load() function.

• Google Code AJAX API's
• Awesome blog post about the pro's and con's

Basically, I ran into this thing where I was using the google.load() to first grab the jQuery core and then immediately afterwards (next line) grab the jQuery UI library. However, I was getting the following JavaScript console error everytime the page loaded:

$ is not defined

The line giving me the trouble was my document ready method, standard fare for jQuery:

$(document).ready(function(){

The problem was that the google.load() function that was off trying to get the core wasn't coming back and processing the core fast enough for the ui library. The jQuery object wasn't initialized yet. The solution was to wrap my jQuery ready method inside the setOnLoadCallback() function, thusly:

// Use the Google API Loader to bring in the jQuery libraries
google.load("jquery", "1.2");
google.load("jqueryui", "1.5.3");
google.setOnLoadCallback(function()
{
$(document).ready(function()
{
...ready code goes here...

The slight delay is actually the fault of the google loader, which kind of stinks because I think it's a pretty cool loader. According to the blog I referenced above, you never get this problem if you don't use the loader and go straight for the remote js library files via script tags. Those apparently obey ordered loading. So, I learned a little this evening. I hope it helps you, too.

Chronicled within this somewhat lengthy post I detail my growing knowledge about how the current implementation of the custom Coldspring lexicon for Fusebox is falling short of my needs. I decided to do some research and try to make it better. Lots of progress was made, but there's more to go. Read on for details and code samples...

Read more...