I was concerned that having my XML files in my config/ folder would be a security vulnerability on my latest MG:U application. After a bit of online digging and doc reference, I found this:

<br /><cfset ModelGlue_LOCAL_COLDSPRING_PATH = expandPath(<span class='cc_value'>"/auction/config/orbitbid/ColdSpring.xml"</span>) /><br />

This allows me to move my ColdSpring.xml file off to a mapped location instead of my web root! You cannot access the mapped locations by browsing to them, but coldfusion still sees them just fine. Inside of ColdSpring.xml, I just modify my configurationPath (and any other necessary paths, including transfer config and generated content folders) to use my mapped location (/mappingName/subFolder/ModelGlue.xml) This just gives me a warm fuzzy that nobody can mess with or view my application configs! For anyone who has not yet tinkered with Model Glue Unity and / or Transfer, you really should take a look. Im already planning on how I can re-code apps I did earlier this year to take advantage of some of the awesome tricks MG:U has up its sleeve.

Tidbits have been turning up around the net recently of a new adobe project entitled Thermo. Mark Ander posted to his blog that the minor leaks have been mostly according to plan. From the MAX preso, Thermo will be able to take a layered Photoshop PSD and convert it to a fully function FLEX application in minutes. Adobe is wasting no time bringing their photo-focused software into line with their RIA and web development aquisitions from Macromedia. Go Adobe!


Added: Link to Thermo on the Adobe Labs site

I maintain some code that made use of InterAKTs WYSIWYG HTML editor. After the coldfusion 8 roll-out, I was getting strange errors on several pages, with this in my logs:\r\n\r\njava.lang.StackOverflowError\r\n at coldfusion.runtime.NeoBodyContent.cfoutput(NeoBodyContent.java:121)\r\n at coldfusion.runtime.NeoBodyContent.cfoutput(NeoBodyContent.java:121)\r\n at coldfusion.runtime.NeoBodyContent.cfoutput(NeoBodyContent.java:121)\r\n at coldfusion.runtime.NeoBodyContent.cfoutput(NeoBodyContent.java:121)\r\n at coldfusion.runtime.NeoBodyContent.cfoutput(NeoBodyContent.java:121)\r\n at coldfusion.runtime.NeoBodyContent.cfoutput(NeoBodyContent.java:121)\r\n at coldfusion.runtime.NeoBodyContent.cfoutput(NeoBodyContent.java:121)\r\n at coldfusion.runtime.NeoBodyContent.cfoutput(NeoBodyContent.java:121)\r\n at coldfusion.runtime.NeoBodyContent.cfoutput(NeoBodyContent.java:121)\r\n at coldfusion.runtime.NeoBodyContent.cfoutput(NeoBodyContent.java:121)\r\n at coldfusion.runtime.NeoBodyContent.cfoutput(NeoBodyContent.java:121)\r\n at coldfusion.runtime.NeoBodyContent.cfoutput(NeoBodyContent.java:121)\r\n at coldfusion.runtime.NeoBodyContent.cfoutput(NeoBodyContent.java:121)\r\n at coldfusion.runtime.NeoBodyContent.cfoutput(NeoBodyContent.java:121)\r\n - repeat like 500 times or so -

Transfer is a system that will allow you to abstract your database from your code, and use a more generic way of accessing your data (as well as a slew of other very cool things). Once it is configured, Transfer will auto-generate methods you can use to read / list / update, and save data to your (insert database software here) server.

Anyway, lets say you have a very simple table, users. You have an ID, fName, lName, etc. Your transfer config could look like this:

<br /><object name=<span class='cc_value'>"user"</span> table=<span class='cc_value'>"Users"</span>><br />   <id name=<span class='cc_value'>"ID"</span> type=<span class='cc_value'>"numeric"</span> /><br />   <property name=<span class='cc_value'>"fName"</span> type=<span class='cc_value'>"string"</span> column=<span class='cc_value'>"fName"</span> /><br />   <property name=<span class='cc_value'>"lName"</span> type=<span class='cc_value'>"string"</span> column=<span class='cc_value'>"lName"</span> /><br /></object><br />

Your object name is your alias, this will be how you refre to it using Transfer. The table is (duh) your database table name, and the ID / property fields define each column in your database. Im not gonna get deeply into the nitty gritty of instancing Transfer or anything, but with this config, Transfer will generate methods to access your data.

<br /><span class='comment'></span><br /><cfset myUser = transfer.get(<span class='cc_value'>"user"</span>, userID) /><br /><br /><span class='comment'></span><br /><cfset myUser.setfName(<span class='cc_value'>"Harry"</span>) /><br /><cfset myUser.setlName(<span class='cc_value'>"Smith"</span>) /><br /><br /><span class='comment'></span><br /><cfset myUser.save() /><br />

Now, on to decorators =)

In case you dont know, the documentation says this about a decorator: "A decorator is used when you wish to write your own CFC to be used to represent data, in place of the Transfer generated Object."

Lets change 1 line in our transfer configuration:
<br /><object name=<span class='cc_value'>"user"</span> table=<span class='cc_value'>"Users"</span> decorator=<span class='cc_value'>"some.path.to.a.cfc"</span>><br />

Now, any methods we have inside of our some.path.to.a.cfc will be included when you create an instance of your user record! You can even over-write built in functions, replacing or supplementing them with your own. You could add a getInvoices() function that, once your user is instances and loaded (using get), you can call getInvoices() to return all invoices for the instanced user. Or, you can build additional functions over top of auto-generated transfer ones. I am digging Transfer, and I love how extensible it is!

I had an interesting conversation with Sean Corfield last night, and while my understanding may be imperfect as of yet, here is what I came away with (I was asking for clarification as to some design patterns for object oriented coding)

The Model - the model should be pretty dumb, this would be the portion of the code that accesses your data. If you use Transfer or Reactor, they would be part of your model. I have several functions that call Transfer, for example:

<br /><cffunction name=<span class='cc_value'>"getItemsByAuctionID"</span> access=<span class='cc_value'>"public"</span> returntype=<span class='cc_value'>"void"</span> output=<span class='cc_value'>"false"</span>><br />   <cfargument name=<span class='cc_value'>"event"</span> type=<span class='cc_value'>"any"</span>><br />   <br />   <cfset var items = getTransferFacade().listByProperty(<span class='cc_value'>"item"</span>, <span class='cc_value'>"auctionID"</span>, arguments.event.getValue(<span class='cc_value'>"auctionID"</span>), <span class='cc_value'>"sortOrder"</span>) /><br /><br />   <cfset arguments.event.setValue(<span class='cc_value'>"items"</span>, items) />      <br />   <cfreturn /><br /></cffunction><br />

These basic dumb getters are also part of my model.

Services - Services provide an interface to your model. For example, I may have a user service with many functions that are application specific. UpdateUser, registerUser, etc. These service functions will make calls to my model (which are the basic getters / setters) and basically route my data to the proper places. My service for user could also be responsible for creating a userBean to persist across the session.

Controller - the controller should handle incoming data from the user, and pass it to the appropriate controller. No application logic will reside in the controller, and in the case of Model Glue: Unity, the controller would be your ModelGlue.xml file. This simply recognizes where the user needs to be directed, and then passes incoming variables from the url and form into whichever service is required.

View - The view is simply display code. This is the only place that display code goes. Your services should make any necessary variables available to the view explicitly, and your view should never interact directly with the URL or Form scopes. If you need variables, your service layer should process those incoming variables (which it got from your controller) and place them into a scope that the view can access. When in model-glue, and inside a controller, you access those variables like this:

<br /><cfset myVar = arguments.event.getValue(<span class='cc_value'>"myURLorFormVar"</span>) /><br /><cfset arguments.event.setValue(<span class='cc_value'>"myVariableName"</span>, myVariableValue) /><br />

From within your view, you access your variables like this:

<br /><cfset viewstate.setValue(<span class='cc_value'>"pageTitle"</span>, <span class='cc_value'>"This is my title"</span>) /><br /><cfset myLocalVar = viewState.getValue(<span class='cc_value'>"varNameFromEvent"</span>) /><br />

Its slow going for me, but I think I am getting a better grasp on the how, and I am getting the feel for the Why, but the why is a bit more slippery =) More to come as I grok it further.