Fusebox. Made to run on several platforms. Backward-compatible for CFMX6, CF5, Railo, etc. Config file was required, then with FB5 it will be optional again.

Mach II. Launched new website, v1.5 is available as a zip.  New features: Multiple XML support, modules, subroutines, URL management (inc. SEO URLs), bindable placeable property notation, declare structs of arrays and arrays of structs in your XML. Persisting complex datatypes across page requests.

Reactor. It is stable. Nothing has needed to happen. It works well. No plans to make big changes.

Not many notes for Model-Glue, ColdSpring.

Presented by Hal Helms.

1. There is a lot of pseudo-OO (affectionately acronymed pOO). What's so bad is that it looks like OO, you have the complexity of OO, but you don't have the benefits of OO.

2. Frameworks and architectures are your friend. Especially the Model-View-Controller design pattern. It is pervasive throughout the industry. Why? Because OO is all about separation. MVC enforces that.

3. Inheritance. How to use it wisely.

4. Beware the guru. Not that they will necessarily give you bad advice; it's just that it hasn't been internalized by you. Don't be afraid to try things and make mistakes. You need to understand why these concepts are good for yourself.

"The opposite of a correct statement is a false statement. The opposite of a profound truth may well be another profound truth." -- Niels Bohr

It's not that procedural programming is wrong. It's just that OO can be better. First of all, it encompasses all the best practices of the pre-OO world. Then, it strengthens these best practices or provides new capabilities. Central ideas behind OO: Encapsulation, polymorphism, inheritance.

When programming, you should personify the code. Thus, you could say object orientation is...

• A way of encapsulating data and behavior in a software construct known as an object.
• Objects have common properties expressed as "I know this about myself.."
• Objects have common methods expressed as "I can do these things.."

So think of methods. Think of objects that just communicate with each other. As an after-thought, what would happen if these objects die, for instance, if the machine was shut down? That's when writing to a database or some other persistence layer comes to play--only as a means to persist the objects. The key is the objects and their methods, not what they contain or how they're stored.

As people, we all are going to go somewhere after this presentation. In the procedural world, you have to get from us our instructions on how to go home, and execute those. In the OO world, you just send me a message, "Nice seeing you; now leave." I then execute that in whatever way I need to do it, and you don't have to be aware of what or how that is.

A component with data and accessors and that's it: Are you really an object? Maybe, technically. But really you're just an irritating structure that only allows access with annoying getters and setters. Real objects should be able to do specialized functionality when asked to do something. Something specific to its identity.

Instead of:

Do something like:

If your CFCs are nothing but collections of functions or wrappers for queries, you're not getting the real benefit of OO.

Model. A domain model is a software representation of your organization. An employee, a customer, an invoice. When you are working in the same environment, your domain model will get richer and richer over time. Components are a great way to implement that.

View. HTML, Flash, Flex, Ajax. Knows nothing of the model.

Controller. Mediates user requests and draws on resources from the model. A "Front Controller", or "Central Controller", is just a controller that will generally mediate all requests of an application.

Inheritance is fun, it's cool. But it is overused. The more you use inheritance, the more dependence your code has, so theoretically it is easier until you start needing to change things, in some cases.

Presented by Matt Woodward.

Why back to front? Starting with the database and moving forward is a good way to understand how all the OO pieces interact. Typically though, you want to start with the UI, and then develop the database according to that.

The most important part of the app isn't necessarily the database; it's the object model. This is obviously related to the database. OO applications should be thought of as nothing more than objects communicating with each other. So the database is irrelevant in that perspective.

Cohesion and coupling. Cohesion is the degree to which an object does one thing and does it well. Coupling is the degree that objects depend on each other. High cohesion--have lots of objects that do specific things. Low coupling--the objects have to speak to each other, but shouldn't be highly dependent on how each other is organized.

Front End / Presentation Layer
|
Controller Layer
|
Service Layer
|
Business Logic Layer

Databases and OO. The DB may not map directly to the objects! Don't try to force-fit objects to the database! Don't do one-to-one mappings necessarily. Data objects will handle the mapping between your business objects and your database.

This is where object-relational mapping (ORM) comes into play. Helps a lot. But build some objects on your own before depending on ORM.

Sample Object: Person "bean". Esentially maps to a single record in the database. It could contain data from numerous tables, for instance, when there is composition (i.e. phones and locations of a person).

DAO/Bean process. Request for person data --> Controller --> Service Layer --> DAO --> Database. DAO puts it in the bean, which gets passed back.

When pulling multiple records, you now may use a Table Gateway. Deals with multiple/aggregate data. Contains methods like getAllPoeple(), search(), etc. Typically may return a query object, because collections or arrays of objects can be pretty slow. Can be done if necessary though, and will perform a bit faster in CF8.

Table Gateway Process. Request --> Controller --> Service Layer --> Gateway --> Database. Gateway returns a query, which is acted upon.

Service layer. The UI and the controller layer should NOT talk to the database directly. Create the service layer and this layer is the API to the entire business layer! So, usually pretty thin in its purpose. But it is very important to make your controller and UI layers easy to maintain.

Controller layer. UI talks to this layer. Can be home-grown, or this is where a framework may jump in. Controller will then talk to the service layer.

User Interface layer. Keep logic limited to presentation logic. No queries.

Compare the controller layer to the service layer: Controller is more concerned about the front-end. Service layer is an API to the business logic. So the controller talks to the service for the UI. The controller is like the behavior of the UI. It's a traffic cop.

Good example described by someone in the class: If your code was a married couple, the UI is one and the business logic is the other. They go through a divorce. The UI has a lawyer and the business logic have a lawyer. The divorcees don't talk to each other; their lawyers talk to each other.

This may seem like a lot of work, but now your back-end can be used in multiple ways. For instance, you could use it in Ajax or Flex. Matt has an example where he replaces the circa-1996 page with a newer-looking interface built with ColdFusion 8 using Ajax. Then changes the UI again with a Flex front-end. Admittedly, he had to build a remoting facade for some of the functionality for the Ajax and Flex front-ends, but the facade was pretty light.

Conclusion

A call to arms: Try this stuff out! The old way is, well, old. You need to develop a comfort level by just trying it. It really is a better way to build things. Remember, the UI may be the last thing we think about as developers, but the UI is the application from our customers' perspectives. Ajax and Flex give that richer experience.

Session started as a Spry overview.

Faster XML Creation

You can use SQL Server to "earn its keep" by automatically returning XML.

This will return XML nodes for all the fields. Then use the sqlXMLToCFXML function to convert the data quickly into a great XML file that you can use with ColdFusion and Spry.

ColdFusion as an Application Proxy

Browser security doesn't allow cross-domain connections. So, we can use CFHTTP to retrieve the XML/JSON from an external site, then render it on your local server! Nifty!

When to use or not use Spry?

When to use Spry? Dynamic content within an HTML page. Form interaction that has to talk to the server. Long-running requests where you want to leave on-screen feedback before finishing. You want interactively changing datasets.

When not to use Spry? Need to use the back button. User needs to bookmark a specific point in a dataset. Server infrastructure is already experiencing heavy load. Unsure of your audience's browser level (lack of support for JavaScript).

New Spry Support in ColdFusion 8

New tags and functions that will help us do Ajax. SerializeJSON(), DeserializeJSON(), IsJSON().

<cfsprydataset>. Creates a Spry dataset with no JavaScript required!

• Name
• Bind: URL of XML or JSON, or even a CFC function.
• onBindError: Gracefully handle dataset errors.
• Options: For other JavaScript optional parameters.
• Type: For determining whether you want to return XML or JSON.
• XPath: For pulling specific segments of the XML.

Between these new tags and the data binding techniques in the Spry specific HTML attributes, Spry makes your HTML/Ajax feel very Flex-ish.  When you bind the data with the Spry HTML attributes, Spry automatically creates the listeners that look for the dataset to change and automatically update the data. Incredibly awesome. Very small amount of code with great desktop application level data connectivity.

Other Notes

ServiceCapture is an awesome tool for tracking the Ajax calls.  Dowload Spry.
CF8 comes with Spry 1.5, but Adobe will figure out a way to get updates to Spry into CF8.