Cutter's Crossing

So, in my last post I talked about setting up a shared ORM model within Mura CMS. But, you always find the kicker after-the-fact. Mine's not a biggie though. I had setup a CF mapping to myModel

Turns out this wasn't the best location. I was pushing to the themes directory, because that was what the client wanted ("What the client wants....") Sometimes, you find a valid reason to deviate.

The Mura {site}/includes folder has it's own Application.cfc, with this wonderful tidbit of code in it:

Now, most of the time this won't matter to you. Until you need to hit a remote method, of your model, for an Ajax request. Then...well, you see what happens. Now, you could probably change the Application.cfc, but I don't know if Mura won't overwrite this file on some future update, so it's better to just move my model into my {site} directory, as a sibling of the includes folder.

This entry was posted on December 1, 2012 at 4:29 PM and has received 2889 views. There are currently 0 comments. Print this entry.

So, I'm working a new project, and using Mura CMS. We decided to write our modules as plugins, and are using the MuraFW/1 plugin template to do so. Thing is, each plugin really needs to share a common model that uses ColdFusion's ORM.

The MuraFW/1 plugin template has facility for defining a cfclocation for ORM configuration, but that location is relative to the plugin itself, so this took a little hunting. Finally, what made the most sense was to define ORM for the Mura site (as a whole), and let that definition propogate down to the plugins.

For those who are unfamiliar with Mura, it's a very nice CMS, and very extensible, but incredibly undocumented. There is some documentation, but it's spotty, and there are articles on their site that are quite dated. (I know this is something they are working on, so I'll leave it at that.) Luckily, I do write code for a living, so I just started pulling on strings until I found the thread I needed.

The MuraFW/1 template's application.cfc includes the core application settings:

That works to our advantage, as anything defined in the core app then becomes available to the plugin. Looking at that file, I started looking for anything related to ORM. The first bit I came upon showed me this:

From there, I had to figure out where ormenabled would come from. I discovered that all of those properties are defined in the /config/settings.ini.cfm file. So, if I added the right properties, I should have my orm configuration. Here is a list of the properties supported by the applicationSettings.cfm at this time:

• ormenabled
• ormdbcreate
• ormcfclocation
• ormflushAtRequestEnd
• ormeventhandling
• ormautomanageSession
• ormsavemapping
• ormskipCFCwitherror
• ormuseDBforMapping
• ormautogenmap
• ormlogsql

So, knowing this, I started looking at my model. First, I placed the model in my theme:

/mysite/includes/themes/mysite/model

This was a requirement of the client, so that was ok for me. Except now, I needed a reference to that directory. A mapping. Mura allows custom CF mappings, by making changes to the /config/mappings.cfm file:

Now that I had my mapping, I needed to setup the ORM settings in that settings.ini.cfm file:

The only thing I was missing was my ORM Event Handler. While the settings allowed me to enable ormeventhandling, they did not allow me to define the handler. For that, I added the setting in my plugin Application.cfc files, right after the initial includes:

I reloaded my application, then updated my plugins (in the Mura Plugin admin) for good measure. Presto! Shared ORM! Hopefully this will help others from spinning their wheels.

Side Note: During this process, I also updated to the Mura v6 Preview. Wow! What an improvement. And the Bootstrap usage should make layout and theming much easier.

This entry was posted on December 1, 2012 at 1:54 PM and has received 3794 views. There are currently 0 comments. Print this entry.