I am overly tired of dealing with heavy site customizations that must take place within these “frameworks” such as Wordpress, Drupal, or Joomla. It is very depressing for me because I have being forced to write bad code which is exactly what has to be done to make a “successful” module or reusable feature for any of these three frameworks. (and many others I’m sure)

My idea of what a good site development framework would be is one that is built on good programming practices and efficiently uses the appropriate design patterns. Using the MVC design pattern would be a must. It has proven it’s success in aiding in the organization of web application code. Needless to say, I have yet to see any of these content management systems properly implement that. I think that a framework that supported drop in module features is always useful for quick deployment and expansion but what happens when you need to customize one of those modules and its built with nothing but spaghetti code?

The majority of the cases that I have come up on thus far when needing to customize a Wordpress installation I usually have to turn to finding someone’s pre-built plugin and further customizing it how it is needed. What my findings have been on the majority of these customizations is that if I would have just built it from scratch from the start, I would have either spent the same amount of time or a little less and had a much higher quality product in the end. The reality is though, some of the things I have to do to make a plugin work in Wordpress is not what I would call quality work when all said and done so it’s really not that valuable to me in the end. I would much prefer that if I were going to write a custom module or plugin for an application, I would rather do it in a well structured development environment that follows good practices for enterprise level development. I don’t think any good programmer would argue that you can’t find that kind of structure in Wordpress, Drupal, Joomla, or any other framework like thoses.

</rant>

The syntax for using this settings manager is really simple as well. It can be initialized in the onApplicationStart method of your ColdFusion application’s Application.cfc file using the code below.

<cfset path = replace(getDirectoryFromPath(getCurrentTemplatePath()), ‘\’, ‘/’, ‘all’)>
<cfset application.settings = createObject(’component’, ‘com.logicalchaostheory.settings.SettingsManager’).init(path)>

Just add the code above and extract the contents of the zip file to the same directory as your Application.cfc file and thats it! To configure your different environments just edit the com/logicalchaostheory/settings/settings.xml file.

I have also considered releasing another ColdFusion class I have written that will use the settings configuration provided by the settings manager class and automatically setup ColdFusion administrator settings based on what environment the application is running from. For example, for a given ColdFusion application you might have two datasources, one custom tag, and an alias that all need setup. My installer class will take settings specified in the settings manager configuration file and automatically add them to the ColdFusion administrator (provided the application has access to the administrator API). If anyone is interested in obtaining this class please post a comment and I will get back with you about posting up the latest source code.

The source code for the SettingsManager class can be obtained here.

The Problem:

The site had a major memory link throughout the modules. I had ultimately determined that this leak was caused by Flex’s mx.controls.VideoDisplay class since I use it in the majority of the modules of the site. The overall problem is that I couldn’t force the unloading of the modules while using the ModuleLoader class. Now this wouldn’t be that big of a deal because I could just not unload each module and instead let the ModuleLoader class retain each module’s instance in memory for later use when loaded again. Well here is where the next big problem came into play, for reasons I still haven’t pen pointed while sorting through the module system’s source code, the ModuleLoader class creates a new instance out of the loaded module every time you call it to be loaded and it does this with the assumption that the old module would always successfully unload first. This assumption has rendered the ModuleLoader class useless when you are experiencing a memory leak within a module that you cannot get rid of. What the result of this problem was is a high end flash site that perpetually grows in memory every time you visit a section of the website, regardless if you have already loaded it once. After browsing this site and hitting random sections for about 10 minutes this would bump Internet Explorer’s running RAM usage up to about 350 to 400 mbs which was clearly unacceptable for it would have kept climbing if I didn’t stop. Also to mention the many other problems this caused with reference less modules floating around in memory still doing their “own damn thing” as they please because they were attached to some globally controlled events.

The Solution:

As this major problem needed a solution and a solution quick I took full and manual control of the loading and handling of the modules by dropping the ModuleLoader class and using the ModuleManager class instead. This nifty class allows to you directly work with the IModuleInfo interface’s that handle the loading and creation of each module used. What I did with this was store a reference to the IModuleInfo instance for each module I loaded in an object using the module’s url as a key/value pair map. This way I could check the status of each module I was trying to load and create one and one instance only of each when it was loaded which I then stored the actual display objects generated from the IModuleInfo in a map of their own allowing me to call them up at anytime I needed to. My ending result was a website that took no more than 150 mbs in RAM once all the modules have been loaded once. Not to mention the performance increase as well when you aren’t recreating a new instance of a module every time you want to use it.

You may download this package here.