I'm getting pretty close to finishing my secret goals for the next iteration of CFMenuCal. To be honest, I don't remember what information I was planning on sharing before it becomes available so I'll tell you a few things now. I've got to keep some secrets though. ;)

• It's getting a new name! I was never terribly fond of the name "CFMenuCal" but I was anxious to get the project posted on RIAForge so I just gave it that boring overly descriptive name. Hopefully the new name will provide a little bit of "branding" or something. The new name doesn't contain "CF", because it's no longer a tool that requires you to use ColdFusion…
• It will be a free online service! In other words: A site where you can go sign up for an account and log in every now and then to create some meal calendars from your stored settings. That means I've already registered a domain and started setting it up. Can you guess what it is?
• Model Glue! This may not be terribly exciting to you, but I'm thrilled about it. This is my first real Model-Glue application, and I'm excited to have a real-world application in an MVC architecture and using a ColdFusion framework.

Rewriting everything to fit into the MVC architecture was a pain in the butt because the code was an absolute mess to begin with. But it has helped because I've already thought of and implemented new features with just a few lines of code. So, what kind of features would make it an even more appealing service to you?

• Would you want an iCal feed so that you can import your menu calendars into your Google Calendar or other Calendaring tool of choice?
• What about saving the finished product as a PDF, so that you don't have to print from your browser?

These are just a few of the things I've been rattling around in my head. What other things would you like to see added? Nothing is off limits here… ask for anything!

In Hacking BlogCFC: Part 1 – Replacing the INI file (read) with XML I showed how you can replace the file blog.ini.cfm with an XML file (blog.xml.cfm) and modify part of the core of BlogCFC to read the data from this new XML format. The motivation for doing so was that on some ColdFusion hosts the getProfileString() and setProfileString() functions are considered a security risk and blocked. Today I'll show you how to modify the setProperty() method of /org/camden/blog.cfc to update that XML file, completing the transparency of the change, by giving the appearance that nothing has been changed at all. In Part 1, I had you modify setProperty() and comment out its contents. Now, go back and replace that (leaving the original arguments in place) with the following: [viewcode] src="blog.cfc.setProperty.2.txt" showsyntax=no geshi=cfm [/viewcode] What we're doing here is loading the XML file into memory, using Regular Expressions to find the setting tag that we want to update, and replacing it with a new one built from the name and value passed into the function. Then we write the XML file back out, and all is well. Notice that I'm still using lcase() on the key name, because we want to ensure that the settings file remains in lower case so that our reading function can find the settings it's looking for. That's it! Now you can run BlogCFC on a host that blocks set/getProfileString(). Happy Blogging.

This is Part 1 of a small series of posts I'm planning on running that will cover hacking (using the term loosely) BlogCFC. For Part 1, my goal is to remove the use of the functions getProfileString() and setProfileString(). What's my motivation? Some hosts consider them a security risk, and block their use. This is the problem I was faced with, at least; and I know I'm not alone! Not to worry, replacing them with XML functionality is a piece of cake! "But Adam!" I can almost hear you scream… "You're using WordPress!" And indeed, that is true (much to my own chagrin). However, I am working on something sort of big, and when I launch it, I intend to move this blog to the new domain, and use BlogCFC instead of WP. That's my real motivation: Getting it to work for myself. Ray has said that he is converting these functions to use XML in BlogCFC6, and that the code is available in the SVN repository. I checked because I didn't want to waste time writing this code if he had already done it for me, but it isn't very complete yet — so there's not too much to be able to rip off borrow.

Note that what I'm about to tell you has a few caveats. Namely, that you'll need to keep the file blog.ini.cfm in place, but its contents don't matter much. Also, I have not tested this on a setup with multiple blogs running from the same codebase, and I suspect that you would run into further difficulties if you were to try it. If that's the case, I suggest you hold out for BlogCFC 6. If there's interest, I might take a stab at including this functionality as Part 3.

The first thing you need to do is convert the INI file to an XML file. I've created one based on the default blog.ini.cfm file — though note that I took out the trackback spam list values for brevity's sake. Just open up your copy of blog.ini.cfm and copy / paste them over. However, if we leave this as an XML file, there would be nothing stopping someone from grabbing your XML file and finding your mail server username and password, and other private information (if the org folder is web accessible, which it shouldn't be if at all possible). In order to protect against that, we'll take our XML, wrap it in a ColdFusion comment tag, and append the ".cfm" extension. This will stop people from being able to find your settings because pulling it up in a browser returns nothing. (You can also edit Application.cfm in the /org/camden/blog/ folder to <cfabort> if the settings file is requested, but it isn't necessary) Here is the entire listing of blog.xml.cfm: [viewcode] src="blog.xml.cfm.txt" showsyntax=no geshi=xml[/viewcode] You might have noticed that I converted all of the setting names to lower case. This is important, and I'll explain why just a little bit later. Next, comment out the two functional lines of code in the setProperty() function of /org/camden/blog/blog.cfc (just like Trond), like so: [viewcode] src="blog.cfc.setProperty.txt" showsyntax=no geshi=cfm[/viewcode] This will let us fiddle with the data reading without having to worry about data writing for a few moments. Now, with that disabled for the time being, let's alter the data reader code to use our XML file instead of the INI file. Open up /org/camden/blog/utils.cfc and replace the body of the function configParam() (after the arguments) with the following: [viewcode] src="utils.cfc.configParam.txt" showsyntax=no geshi=cfm[/viewcode] This will load our XML data into memory, strip the CFML comment tags, parse it as XML, search it using the XPath expression settings/setting[@name='#lcase(arguments.key)#'], and return the value attribute of the first matching "setting" node found. Again, notice that I'm using lcase() on arguments.key. This is because we can not be sure that the keys are always requested in the same case in other functions, and case matters when searching XML. So searching for "DSN" and "Dsn" could potentially return different values. To get around this, we're converting all requested key's to lower case, and earlier we converted all of the key names (setting names) in the XML to lower case. Now, searching for "DSN" and "Dsn" both actually search for "dsn", and return the expected value. If we leave things in their current state, then your instance of BlogCFC will read its settings from the XML file. You won't be able to update those settings without manually editing the XML, because we don't yet have a facility to write changed settings back to the XML file. So to change a setting, first update the XML file, then go into your blog administrator and click the "Refresh Blog Cache" menu item. In Part 2, I'll cover the new setting-writer functionality, so that everything works transparently, as if it were still using the INI file.