musings on software development, writing and life

Ok Bender seems to be generating some interest and I’ve found that a lot of people aren’t really understanding my explanation of what it’s supposed to achieve, so here’s an attempt at a clearer definition.

If you’re writing a flex app with database connectivity, your workflow should look like this:

1. Install Transfer on server
2. Write Transfer.xml
3. Install Bender on Server
4. Run Bender AutoGenerating Tool
5. Include the resulting SWC library in your Flex App
6. Instantiate the generated classes in your flex app, fill ‘em with data, and make calls to Bender as you would to Transfer – for example Bender.save(myProductClass)

That’s it – nothing more complicated. The primary idea is to give flex developers a seamless access to the benefits of database persistence via Transfer. In theory, if you can setup Transfer, you can add db persistence to your flex app with Bender, without any CF knowledge.

Bender itself is comprised of 3 components – Bender.cfc, Bender.as and BenderAutoGenTool.cfm. Bender.as gets compiled into a swc along with classes for all your objects defined in the Transfer.xml. Bender.cfc sits on the server.
Looks like this:

Here are a couple of examples of how something might happen:

Creating and Saving an object:

The steps in this workflow are as follows (assuming Product.class is one of the autogenerated actionscript classes):

1. Instantiate Product.class and use setters to fill with data
2. Call Bender.save(myProduct);
3. Bender makes a RemoteObject call to the Bender.cfc save() method, passing the actionscript class, which Flash Remoting will convert into arrays and structures
4. Bender.cfc looks at the received data, determines which TransferObject it needs and instantiates the relevent TransferObject
5. Bender loops through the data received, calling matching setters on the new TransferObject
6. We check to see if we have a specific hander (CFC and method name) for save() on Product objects
7. If we don’t have a specific handler registered then we pass directly to Transfer itself, using Transfer.save(ProductTransferObject) – END
8. If we DO have a specific handler registered, we pass the TransferObject to that cfc and method instead, for example ProductManager.save(ProductTransferObject)
9. ProductManager.cfc does it’s thing, making any required manipulations to the ProductTransferObject
10. ProductManager.cfc then passes to Transfer using Transfer.save(ProductTransferObject)

Before anyone asks, in the above example I haven’t bothered setting out the steps for the case in which ProductManager.cfc does validation and has to pass it back with messages etc, but the ability would be there (I haven’t decided yet on any specific way to handle this, but that will come).

Here’s an example of retrieving an object from the flex app – imagine you have a form in your flex app allowing the user to enter the id number of a product, and you want the app to then retrieve that product.

1. User enters an ID and requests the product
2. Call Bender.get(“product”, productID);
3. Bender makes a RemoteObject call to the Bender.cfc get() method, passing the productID as a parameter, also passing the classname of Product and the action GET
4. Bender.cfc looks at the received data to determine the Transfer classname we’re looking for
5. Bender checks to see if there is a specific handler registered for this class and action
6. If we don’t have a specific handler registered then we pass directly to Transfer itself, using Transfer.get(classname, arguments.productID) – SKIP TO 10
7. If we DO have a specific handler registered, we pass the cfc and method to that handler instead, for example ProductManager.get(arguments.productID)
8. ProductManager.cfc does it’s thing, making any required manipulations to the ProductTransferObject
9. ProductManager.cfc then passes to Transfer using Transfer.get(classname, arguments.productID)
10. Transfer returns the requested TransferObject back to either Bender.cfc or ProductManager.cfc accordingly (10.5 – PageManager.cfc then passes the Product TransferObject back to Bender.cfc)
11. Bender.cfc pulls the data out of the TransferObject and puts it into structs and arrays
12. Bender.cfc passes the resulting struct back to Bender.as as the result of the RemoteObject call
13. Bender.as takes the received data (which Flash Remoting has converted into a simpe AS Object) and instantiates the required AS Class (IE Product), using the setters on the the newly instatiated Product to pass in the received data then passes the ProductClass back to the Flex app
14. Whatever handlers are in the flex app for this event are fired and the flex app does it’s thing

Hopefully this all makes a bit more sense. Please bear in mind that it’s not 100% finished yet, and when it is, I’ll be asking for feedback and may change the way some of this works if somebody sees a better way to do it. I hope that for now this will serve as a better explanation of what I’m trying to achieve.

Tweet This Post

Related posts:

1. Bender Expansion
2. Bender persistence
3. Bender Revived
4. Mind-Bender
5. Bender has deep composition