Codito Ergo Sum

I am writing code that will replace a legacy CF system. At some point in the past this system was forked to run a 2nd company, and the web root was copied to another folder. Of course, over the years the 2 systems diverged, fixes were not always put into both, and gradually the single code base become twice as hard to handle. One of my goals for this new system was to write it such that many sites could share the same code base.

Read more...

While I don't make any claims at being a model-glue expert, I did come up with a way to run my multi-step forms in model-glue. I basically use a single 'event' entry point that has several named results, and the single entry point controller runs 'makeEventBean()' against my form bean (kept in session), and then passes the bean to the service and asks 'what is my next step?' The next named step gets fired off to the named result, and the user see's the appropriate screen in the multi-step process. I am using Transfer ORM, so inside the service you will see some use of that code. Also, I am not going to paste the display files here, this is just really to blog about the gist of my methods to handle a multi-step form. There are quite a few little code chunks here, so without further ado...

Read more...

Often times when I am writing ajax or model-glue apps, something will go wrong and its difficult to see the values that are complaining. Sure, you could pass things forward to the view, catch/try, maybe set your controller to allow output and dump it from there, but this little custom tag seems to do the trick most of the time for me.

<cfset dumpMe = attributes.var />
<cfsavecontent variable="debug">
   <cfdump var="#dumpMe#">
</cfsavecontent>
<cffile action="write" file="#attributes.file#" output="#debug#">

its called 'fileDump.cfm' in my custom tags folder, and you use it just like you would think:

<cf_filedump var="#varToDump#" file="c:\debug.html" />

Now I will get a nice file I can open up regardless of the final rendered output of my page / event, and see what the heck is going on. You can dump the entire event, or the 'this' or 'variables' scope as well, and get the whole ball of wax in a nice file that you can dig through at your leisure!

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("/auction/config/orbitbid/ColdSpring.xml") /><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.

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="getItemsByAuctionID" access="public" returntype="void" output="false"><br />   <cfargument name="event" type="any"><br />   <br />   <cfset var items = getTransferFacade().listByProperty("item", "auctionID", arguments.event.getValue("auctionID"), "sortOrder") /><br /><br />   <cfset arguments.event.setValue("items", 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("myURLorFormVar") /><br /><cfset arguments.event.setValue("myVariableName", myVariableValue) /><br />

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

<br /><cfset viewstate.setValue("pageTitle", "This is my title") /><br /><cfset myLocalVar = viewState.getValue("varNameFromEvent") /><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.

I sent an email to Ray Camden a few months ago to let him know that his application XML for one of his sites was exposed, showing off his logic basically. He mentioned that you can change those XML files to be .cfm and do some tweaking to hide them from other people, but it sounded like a pain. Read on how to fix!

Read more...