Since my recent move to Linux I have been slowly but surely getting my development environment set up. In Ubuntu 8.10 it is fairly painless to get an ACME server up and running quickly. Apache, MySQL, and Eclipse are easily installed through package managers or using CLI tools in the shell. ColdFusion is easy enough to install as well, the main issue I had during my installation was the fact that ColdFusion did not start when the system booted using the install scripts installed by Adobe. Apparently the installer only likes RedHat and SuSE Linux so I had to do a little poking around to get it starting up automatically.

I will be the first to admit I currently know just enough about Linux to be dangerous. At any rate, here is how I got it working in case it may help someone else. If any gurus out there see me doing someone that is obviously wrong, please let me know!

First I created the scripts in /etc/init.d/ that will be used to start and stop the ColdFusion server. Using vi (running as root of course) I created coldfusion_start.sh and coldfusion_stop.sh to start and stop the ColdFusion server, respectively. The files short and to the point. As an example, here is my coldfusion_start.sh script:

The coldfusion_stop.sh file is almost identical except we send the stop parameter instead of start.

After getting the scripts setup, we need to be able to execute them which is easy enough to do with a "sudo chmod +x /etc/init.d/coldfusion_start.sh" and "sudo chmod +x /etc/init.d/coldfusion_stop.sh" without the quotes, of course.

Now here is where my process gets a little less than scientific. Starting with /etc/rc0.d/ and working my way to /etc/rc5.d/ I looked for any symbolic links that had the Apache daemon starting or stopping. If Apache was starting I created a new symbolic link to my coldfusion_start.sh script and if Apache was stopping I created a symbolic link to the coldfusion_stop.sh script. I always made sure that ColdFusion was started or stopped after the Apache service.

For example, the link to kill ColdFusion in /etc/rc0.d/: sudo ln -s /etc/init.d/coldfusion_stop.sh /etc/rc0.d/K90coldfusion

The link to start ColdFusion in /etc/rc3.d/: sudo ln -s /etc/init.d/coldfusion_start.sh /etc/rc3.d/S95coldfusion

In retrospect, it may make more sense to stop the ColdFusion server before the Apache server is stopped but currently I have it starting and stopping after Apache. However, everything appears to be running smoothly.

While my blog has been quiet lately, I have been quite busy. Many months ago I wrote a post about moving my development machine to Linux. That lasted a few days when I got aggravated by my own shortcomings and promptly switched back to Windows. Lately I have been trying to focus more on open-sourced alternatives so yet again I have switched back to Linux. To avoid another premature post I decided to "stick" to it for a while and so far so good.

[More]

It seems it has been very quiet around here the last few weeks. It has been hectic at work having to make sure everything was prepared for potential hurricanes as well as taking care of some other client projects I have been working on.

I have also been doing a lot of work (ahem, playing) around with jQuery learning AJAX and how to pass data back and forth between jQuery and ColdFusion. I've had a few neat successes and more than my share of flops, but it has been a learning experience and pretty fun at the same time.

Development has stalled on WhosOnCFCDB, but I plan on resuming development on it to get it up to the same functionality in WhosOnCFC 2.2.3. As one user pointed out there is no documentation for it and I plan on getting that remedied up shortly as well. As I noted in a comment about the situation, the docs for WhosOnCFC and WhosOnCFCDB are pretty much the same and I published the current docs up on Google Docs and they can be found here:

http://docs.google.com/Doc?id=dhjwqsht_12c77dd7cn

Well, it is done. I zipped up my current version and have released it to the masses. If you are interested in checking out the new version, you can point a browser to http://whosoncfcdb.riaforge.org and check it out.

A few things are worth mentioning to help get you up and running if you would like to use it. I did not include the latest version of Transfer ORM in the distribution package. If you do not already have Transfer up and running your can get the newest version at http://www.transfer-orm.com.

All the Transfer related XML configurations as well as the MSSQL SQL generation script can be found in the /config folder. You will need to modify the datasource.xml file to the ColdFusion data source you will be using. Use the supplied whosoncfcdb.sql to generate your tables for you. As mentioned before, I do not have scripts for other database servers so if someone comes up with one for MySQL or another server please let me know. The data structure is simple and you should be able to look at the transfer.xml file and piece it together.

If there are any questions you can post them here and I will do my best to get them sorted out as quickly as possible.

I went ahead and submitted WhosOnCFCDB to RIAForge this morning. I was thinking it may take a little bit of time to get it approved since Ray lives next door to me, more or less, but apprarently it is hard to keep him down, hurricane or no.

WhosOnCFCDB is currently at version 0.9 which is a retooled version of WhosOnCFC 2.2.2 using Transfer ORM to handle storing user information as opposed to storing everything in an instanced component. This will make it easier for those of you who have WhosOnCFCDB running on multiple web sites and should allow you to monitor everything from once central location.

WhosOnCFCDB requires Transfer ORM 1.1 RC1 or above, any version prior to that you may encounter some problems.

As soon as I get things finished this afternoon I will upload it to RIAForge. It should be noted that this is a beta release so the documentation is sparse. I only have the SQL scripts for MSSQL server, any other SQL server will require some editing by hand, but the database structure is not very complicated.

Well, this is the third and final installment of my blog posts dealing with my crash-course in Transfer ORM. On the first day I roughed out my transfer.xml file that detailed my database structure and wrote the rudimentary functions that compose the gateway object WhosOnCFC uses to communicate with the database. On the second day I fleshed out some new functions that mimic the array functions in WhosOnCFC. Day three links the ActiveUsers table with a One-to-Many relationship to the PageHistory table which stores each page viewed by a session.

[More]

You can find the demo application here: http://amary.kisdigital.com

Well, instead of adding any additional tables to my transfer.xml, I decided to just finish adding the functions in the gateway object to make everything run as it should.

Everything seems to be running fine with the exception page loads are a little slow for my tastes. I will post the revised code for my gateway object and if anyone sees any obvious problems with it, any help would be appreciated. I decided to keep all the database interactions in Transfer as this was a learning experience.

[More]

I will preface this by saying the only Transfer experience I have thus far is installing it. Since that only required copying a folder onto the web server and adding a ColdFusion mapping, I am far from a Transfer expert and this will end up being a bit of a learning experience. I was going to put all the database interaction inside the WhosOn.cfc component, but after some consideration I thought it might be better to follow best practices and separate my service object from the gateway object.

[More]

Yesterday I acquired a contract for a few weeks of work. One of the things the client was interested in was a DB back-end for the latest version of WhosOnCFC. In my opinion one of the best qualities of WhosOnCFC was that a database was not required for it to operate, it was set and forget, but I can see where having the information in a database could be a good thing.

This will also be the first project I have using Transfer ORM. It allowed me to write the database support in less than 30 minutes, which I thought was really impressive. Now I just need to finish up everything else.

Well, yesterday I started looking at Model-Glue, Transfer, and ColdSpring again. After about 14 hours of playing around I am starting to understand the flow of writing MG applications. Also, examining the code for Ray's CFLib2008 project helped quite a bit.

One of the biggest sticking points with MG, when you are not very familiar with MVC architecture it can be frustrating. For example:

Above is a simple controller with just one member, getUsers(). It works fine as is, but remove the beans="userService" in the component definition and you may find yourself speaking in tongues. Well, I was anyway. ;) I know it may be common sense for some of you, but it is the first time I have ever encountered it. If it wasn't for Ray's CFLib2008 code I would be speaking in tongues still.

I suppose I understand events and event-listeners and handling views. I suppose I need a better understanding of how to use my objects within the framework.

Against someones advice I was playing with Transfer and ColdSpring at the same time as well. Actually, these two apps were much easier to wrap my head around than writing MVC code. After seeing how easy it was to implement Transfer I could almost slap myself for being too stubborn to use it before.

Really I haven't done too much with ColdSpring as of yet as I don't have many components in my "learning application." There is always tomorrow.