Circular dependency is a concept that's been around a long, long time and most people who do OOP style programming are aware of it. But in my own personal experience, there are very few real instances where a use case exists for implementing it. I am currently working on a project, though, where circular dependency is exactly what the doctor ordered, so I thought I'd share the use case for the next time someone teaching OO concepts needs a real life example.

JBase is a class that is used within a project to act as a relational database (it’s a singleton that persists its data in json files written to disk). It has one other class which it aggregates, called JTable. JBase behaves as a database, while the n number of aggregated Jtable instances behave as individual tables within that database.

JTable is a “smart” table…performs its own saves, finds, deletes, etc. One of the other functions that JTable has is the ability to join itself to other JTable instances to which it is related. But, those other instances exist within the parent JBase instance, so JTable must reference it’s parent JBase instance in order to interact with the related JTable instances.  Feel me dawg?

On a side note, I do plan on sharing JBase as soon as I am finished with it. I don't know if it's actually overly useful to anyone, but hey, you never know. :)

Doug out.

The Scenario

My last Mura post was on how to include Ajax functionality in a Mura site. In my case, I needed to add this functionality to the home page (very topmost in my page hierarchy), and I did so by placing a component into that page's "main content" area. Well, this was all find and dandy until I realized that, because my home page is being inherited by many of the children pages (due to some sidebar links I wanted to cascade down), my ajax component was ALSO being inherited. No bueno. The topic of this post, then, is how to add a component to a page and not have it to be inherited by child pages.

The short answer: Rather than add the component via the "content objects" tab, output the component within your page content manually.

Since page content is not inherited by children (only items added via the "content objects" tab are inherited), this approach ensures that the component is only rendered for that page alone.

DETAILS

Not much to this, really. We will utilize a Mura command called "dspObject" to perform the manual rendering of the component. dspObject requires the ID of the component you want to render, so you'll need to grab that first thing. To find the ID, go to Components, edit the component you're interested in, click on the "Advanced" tab, and copy the Content ID value.

Lastly, we output the component in the page content we're interested in. Just add

to the page content where you want the content to appear.

That's it! Now your component will appear within your page, but will NOT be inherited by any child page.

Doug out.

Part of the process of porting our company web site over to Mura involved including some ajax functionality. I spent a few hours researching and experimenting, so thought I'd share what I learned in case it saves someone else some time later.

The Scenario
The site you're porting to Mura currently retrieves and outputs a list of scheduled events, and you need to have that same ajax call working within the Mura site as well.

How it Works In a Nutshell
In order to accomplish our goal, we need to:

• get our JS library loaded;
• get our custom ajax JS code loaded;
• get our backend code (that responds to the ajax calls) in place;
• keep our ajax code modular so that we have flexibility with what pages we include it on and in what position.

Loading our Library and custom JS
The fact is, Mura already by default has JQuery loaded up and ready to go (if you'd like to change your default library to something else, such as Prototype, check out step 1 of this Mura article). As you know, however, the order that js files are loaded up is very important. For instance, loading up our custom JS file before our library gets loaded means that our custom js code will not execute and will likely error out. So, you have a couple of options here:

Keeping our code modular
The obvious answer to this one is to utilize a Mura Component to contain our Ajax. We'll call this component "Show Events". This component will contain the div that our ajax call will populate with content as well as the js code that does the populating.

Backend Code
My backend code for this exercise is a simple CFM page named registrationAjax.cfm that contains a cfswitch/cfcase statement that responds to ajax calls. I will be placing it in the following path:
[mura installation folder]\[site name]\includes\display_objects\custom\registrationAjax.cfm

THE DETAILS
Okay, let me show you how I put this all together, elaborating along the way as I feel the need.

Backend Code
As mentioned previously, I dropped my backend code into the [mura installation folder]\[site name]\includes\display_objects\custom folder. Your backend code may very well live in a galaxy far, far away; not a prob. It's ajax, man! If your backend code lives elsewhere, just forget about this step.

The Ajax Component
Okay, our component is going to include the target div where our retrieved event data will be output:

Loading the JS File
Just FYI, here is the content of my js file:

 When the page this code lives in finishes loading, an ajax call will be made to my backend code, the result of the call being placed into the 'eventTarg' div.

Next we need to place our js file somewhere. I opted to create a "custom" folder under my site's "js" folder, like so:
[mura installation folder]\[site name]\js\custom

Bogus (yet necessary) Step

Here we come to a step that I feel is kinda bogus to have to do, but never the less it's required by Mura when you want your JS to live in an external file. Rather than us just being able to add a string like "<script src="[path stuff]/myjsfile.js"></script>" to the head of our page, Mura requires us to create a CFM template that itself contains that string, then we add that cfm page to the head. I know, sounds (and is) a bit overcomplicated, but this is how you have to do it if you want your JS in an external file. SO, I added a "custom" folder to my [mura install folder]\[site name]\includes\display_objects\htmlhead\ folder. In there I created "loadShowEventJS.cfm" which contains the following code:

Now that we have that file created and in place, we need to revisit our component and add two lines that will put our external js file into the page's head AND ensure that it is loaded AFTER the JQuery library. Add these two lines to your component:

This is an excellent time to point out the use of Mura's addToHTMLHeadQueue function. It takes a path (relative to the display_objects folder in your site). Whatever the final rendered content of the targeted CFM file is, that is the string that will be included in the head of your page. Notice we're also using the loadJSLib method to ensure that our js library (JQuery in this case) is loaded before our custom js file. Even though by default Mura is ALREADY loading JQuery, if we don't use the loadJSLib() method here, JQuery would load AFTER our custom js file. For more information on the addToHTMLHeadQueue method (and every other Mura method), I highly recommend you bookmark the developer mura docs

That's It!

I know, it wasn't quite painless. But at this point you can go ahead and test it all by adding your component to a page and then viewing it. There are a lot of moving parts to this, like paths and your ajax code itself, so just bear that in mind if things don't work quite right the first time 'round.

 
Simpler Method
If having your JS live in an external file isn't a big deal to you, then there IS an easier way to get your ajax functionality into your page. Remember I told you that the JQuery library was already being included by default? Well, if we opted to put our JS code inline within our page body, then it would work just fine without us having to tell Mura where to load JQuery within the head. So in this scenario, we need only modify our component code to look like this:

Porting a static HTML site over to Mura is one thing, but porting over existing Coldfusion functionality is another entirely.

The Scenario

In this scenario, my old site has a dynamic form CFM page (content driven by incoming parameter values) and a matching dynamic action CFM page. Let me show you the approach that I took to incorporating this functionality in to the Mura version of the site.

As you know, Mura offers its user a pretty little WYSIWYG editor for creating page content. All fine and dandy, until you need to execute Coldfusion code within that content. Though there are, I'm sure, several ways to skin this cat, the approach I took was to leverage Mura's "[mura][/mura]" tag, along with Mura's "components". Here are the steps to accomplish this, at a high level:

My Solution: High Level

1. Create a component that will act as your Coldfusion code holder. Within this component, "include" your real Coldfusion template ([mura]dspInclude('[full relative path to cfm template]')[/mura]). Important: The CFM page itself needs to be located at the following path:

That's it!

Now why I couldn't find a single example of this SIMPLE two step process out in the ethersphere I'm not sure, but that really is how simply I was able to accomplish this task.

My Solution: Details
Okay, now that I've gone over this at a high level, let me add a few more details and illustrations for those who like/want/need that sort of thing (like me). In my real life example, I'm porting over a registration form and a form action, so the details will be within that context.

Step 1
Creating the components. Well, I'll just let the picture say it.

Step 2
Add the component to the page that will display the output of the CF code via the "Content Objects" tab. (Note: You CAN still have content created via the editor, but to include the CF functionality, you do it via Content Objects.)

I haven't talked about the action code yet, but let me say that it is exactly as described above; create a component containing the action code, create an action page, include your component in your page. A few caveats to be aware of regarding this:

1. The form action on your registration page will be a Mura link to the action page, and will look something like this:

/[site name]/index.cfm/saveRegistration/

2. On your action page, you'll want to be sure and uncheck the "Include in Site Navigation" box. Also, even though instinctively you'd probably want to set the "Display" option to "No", you need to keep it as Yes. In Mura, "Display" doesn't really relate to if the page is a display page or not; it's more of an "active/inactive" flag. If you choose No as Display, then Mura will think your action page doesn't exist when you try to call it.

3. Just an FYI, you CAN pass variables via form post or URL from one page to another. The action page will see a complete form scope, and passing URLs is as simple as /[site name]/index.cfm/saveRegistration/?myParam=bla

Hope this helps someone! And, if anybody has a different or better approach to porting over CF functionality to Mura, PLEASE say so in the comments!

Doug out.

Preface (aka, my rant)

Skip this preface and go directly to The Scenario if you're not interested in my opinion (thus far) on Mura. Some of it is good, some of it is harsh and opinionated. Never the less, ranting is therapeutic for me so I have to do it.

I finally got fed up with making changes to the company web site and decided that porting it over to a CMS and letting my coworkers make their OWN changes was the answer to my finding peace and tranquility. Being a CF guy, and being unable to recollect the name of any CF-based CMS other than Mura, I decided to take the plunge with that product. How hard could it be, after all, since our company web site is 95% static HTML? I found out that it wasn't NEARLY as easy as I believed using a CMS should be. Not having ever used any other CMS, I can't attribute the pain to Mura specifically as it is very likely that any CMS would come with the same level of learning curve; but I can say that there has been pain involved.

I think the single most important thing you should do before you decide you're going to use Mura is to adjust your expectations. If I had been thinking of it more in the light of learning to use a new framework, I don't think my initial impression of it would have been nearly so negative. Once I realized that Mura really is a complex animal and that anything beyond the very basics requires customization in one way or another, it became more palatable to me. Now, it could also be that the fact that I was porting an existing site and not merely creating a site from scratch made my learning curve more difficult, as it became necessary for me to be intimately familiar with files and folder structures that I probably would not have had to otherwise. And the fact that, although the documentation on the site seems fairly robust, it is written in the context of previous versions of Mura; the current version has a different folder structure, file names and locations, and an entirely different editor. So to figure out how to do what I thought should be simple things (like customize the styles in the editor, the theme of this post) ended up costing me hours of googling, trying to interpret and map old documentation to the newer version, and skimming through Adobe Connect recordings on the topic. I did of course eventually figure it out, and so decided that I would blog the things I learn along the way in order to save others a little time and pain, should they decide to embark on this same Mura CMS journey.

Now for the plugs. Mura is aMAZINGLY robust, IS customizable, has the ability to utilize plugins written in FW/1, and can be made to jump through fiery hoops if you're willing to get your hands dirty in its guts. It's free, and you can't beat that price; and even without paying for support, there are many various and sundry resources out there (living and written) to help you eventually grope your way through your issues. Okay, I'm done ranting.

The Scenario

You're porting your company's current static site over to Mura in order to allow your co-workers to make their own changes. None of them know what HTML is, so in order to give them the ability to style the content with ease, you want to add styles to the dropdown list in the editor. This scenario also assumes that you have opted to create your own theme for your site.

The Solution

Let's just break it down into the simple steps it takes to accomplish this. I'll elaborate as needed afterwards.

Step 1: add your css styles to the "typography.css" file.
 (note: This file can be found at the following path: [path to your webroot]\[your mura folder]\[your mura site]\includes\themes\[your theme name]\css\typography.css)

Step 2: add your styles to the CKEditor styles.js file
 (note: this file can be found at the following path: [path to your webroot]\[your mura folder]\[your mura site]\includes\themes\[your theme name]\js\editor\styles.js)

That's it! Now, why I didn't find this solution in all of my googling, skimming through hours of Mura Connect recordings, and perusing of Mura documentation, I do not know (oops, I'm ranting again!). But, those two steps ARE the answer to that question. Now, let me elaborate a little for clarity's sake.

Clarification/Details

Step 1
For example's sake, let's say we want to add the following style to the dropdown list: "Fancy Header". We're going to assign an actual class of ".fancyheader" to this, so we make the following entry in our typogrophy.css file:
.fancyheader {
 font-family: ‘Palatino Linotype’, ‘Book Antiqua’, Palatino, serif;text-align:center;font-size:20px;font-weight:bold;
}
Save it, and you're done.

Step 2
Now we want "Fancy Header" to appear in our CKeditor's dropdown. So we open up our styles.js file, find the area where the existing styles have been defined, and simply add a line that follows the pattern. We started out with this...

 and we added a line and now have this...

 And that is REALLy all there is to this. Hope it helps someone.

Doug out.