I'm not a very advanced user of SVN, and up until now I've used TortoiseSVN as the client of my choice. However being that I now have a mac at home I needed to find a SVN client for OSX. However I could not find anything that looked as easy to use as Tortoise.

I've been using (CF)Eclipse for quite a while, but for some reason I always thought that Subclipse is a advanced/difficult SVN client. However, realizing that I should probably learn it I decided to go ahead and (try to) use that on the mac.

To make it short: It's awesome. It's every bit as easy to use as Tortoise, and the fact that you create a new Eclipse project as part of setting up your local working copy is one of those things that really makes it worth while.

I've just scratched the surface of Subclipse yet, but it is the SVN client of choice for me from now on - yes, even on Windows machines.

Some of you might be thinking something along the lines of "Instead of just going on about how easy and great it is - why can't he tell us how to use it?". Well my friends, I see no reason to, because there is already a VERY GOOD explanation available, and which is the one I used to get started. It's written by Aaron West and can be found at his blog.

So Aaron, if you ever read this, Thanx a lot mate!

My before mentioned framework newBee is now on RIAForge. While the version currently in the SVN respiratory is not meant for the public (there is some stuff I need to clean up - and some documentation to be written), it is there. Mostly because I needed/wanted a SVN repository for it.

While I did not intend to go public with it quite yet, it has been reported several places that it is there, and so far the project has more than 500 views. So I see no point in not blogging about it myself :)

Today I added the forum option in RIAForge, seeing that many have been visiting and may have some questions, or other input about newBee.

I hope to get some time during Easter to finish version 0.5 which will be a stable, but maybe not optimized and feature complete version.

I hereby declare Mark Drew winner of the Man of the Month award. The work Mark does with CFEclipse is nothing short of amazing. I think his attention to the needs and wishes of the community by far exceeds what most commercial enterprises do.

So Mark, as you know I don't drink (alcohol that is), but never the less I raise my virtual glass of Jack Daniels in praise of you and the work you do with CFEclipse.

I encourage all that reads this and who are using CFEclipse to leave a comment raising your virtual glass as well!

First let me say I'm sorry for the delay with this post. I've been laying home with a serious case of the flue.

Ok - we saw in part 3 that the newbee.xml file holds the "key" for all the information flow from the view to the model and back. This is the big picture, the overview of the application of sorts.

There is one more xml file in the config directory though, simply called config.xml. It looks like this out of the box:

The first config node called "defaultEvent" is needed in order for the application to know which event (specified in the newbee.xml file remember?) to run when no event is specified in the url or form scope.

The other config node is an example on how you can set application wide variables.

The idea is simply this:

newbee.xml holds the information that will not change once the application is developed, while config.xml holds information that might change with each installment of the application (like data source info, mail server info etc.).

A little inconsistency is that defaultEvent is not likely to change from installment to installment though.....

The current version of newBee is a Alpha 0.3 version. I expect it to go public beta at the 0.5 version, so things might still change.

We have seen that we can have a model cfc and a view template, that does not know anything about each other at all, but still work together.

The way we "stitch together" what model part and what view parts play together is with the newbee.xml file in the config directory. The newbee.xml file is wher you make all conections between the model and the view, and works a birds-eye view of what your whole application looks like.

Let's have a look at what it looks like right now:

For now we'll look at the model and the view node defined under the event named "default".

The model node has a path to a cfc, relative to the model directory (you can use subdirectories within the model directory), it has a method, which we remember from the cffunction name in the HelloWorld.cfc code we looked at. And we have a returnvariable, which we see is equal to the variable we used in our mainpage.cfm code example.

Then theres the view node that contains the path to the mainpage.cfm file, relative to the view directory.

So we see that to instruct the controller (newBee framework) to connect the model and the view is very easy, intuitive and straightforward.

One of the basic ideas of newBee is that you should be able to put a newBee application into any directory or subdirectory (as deep down as you like) and it should run, without the need to set up any mappings and without the need to put any framework files directly under the webroot. Upload and run! Yeah baby!

So installation of newBee is to simply copy the newBee (newBee application skeleton) files, or a ready developed newBee application and put it in a directory on a CF enabeled webserver.

Ok, for some (probably most) application you will be required to set up a data source, but that is not specific for this framework.

When you have copied the newBee application skeleton into a directory you can open the application in your web browser. You should then see something like this:

Having opened the site above you've in fact opened up a newBee application. Let's look at some code:

model/HelloWorld.cfc

view/mainpage.cfm

Here we see the entire model and the entire view at work. We have a cfc which has a function called HelloWorld that returns a string, and a view page that outputs a variable. We also see that the cfc and cfm file have no knowledge about eachother what so ever. This makes the code very flexible and reusable.

Next time we'll have a look at the xml files. As said earlier newBee is the controller layer between the model and the view, and the xml files is where you "instruct" the controller. Don't worry, it's not hard at all. Remember "Simplicity is the key".

So I've decided to get newBee out in the open. I just thought I'd start of by giving a very short introduction of the very basic functionality.

newBee is ment to be a very easy to learn and use MVC (Model-View-Controller) framework, where newBee acts as the Controller between your Model and your View files. Simplicity was my guiding word in making this framework.

The purpose is that your Model and View files should not know about each other. The goal is structure, re-usability and maintenance of your code.

So here is the root structure of a newBee application:

- Model
- View
- Controller
- Config
- application.cfm
- index.cfm

So, as you'd guess, your model (cfc's) goes into the Model directory. Your view files goes into the View directory. The controller directory contains the newBee framework files (you should not go in here unless you want to modify the framework itself). The Config directory holds the XML files you use to "instruct" the framework.

The application.cfm and index.cfm files should also be left as they are.

This was the simplest root structure I could think of for a MVC framework. Remember "Simplicity is the key".

Later today I'll try and get time for posting some code.

In the last issue of The Fusion Authority Quarterly Update Jared Rypka-Hauer has an article called "An Introductions to Frameworks". He goes through six of the mostly used CF frameworks, but in the summary he goes on to saying:

"Other frameworks that bear mention are.... NewBee, a very new and nearly-unheard-of framework from Norway that uses a combination of CFM files and CFCs to accomplish MVC while keeping itself embedded within the application rather than relying on the inclusion of external framework files like the others..."

Now nearly-unheard-of is an understatement, at least until it was mentioned in FAQU :)

So this was the needed kick in my but to dust of the newBee framework. I have an application for a client in work that will be just perfect for me to refresh newBee before making it public.

And what is newBee you might want to ask. Jared did a good job of describing it. From the newBee projcet page (also not published yet) you can read:

"NewBee is an extremly lightweight and easy to use framework for making ColdFusion application in a MVC pattern."

Most of the websites I work on has Norwegian as the main or only language. To make sure Norwegian letters (æ,ø and å) looks good in web browsers we have to use UTF-8 as page encoding, and also insert a BOM mark.

In Dreamweaver this is really simple to do, and I've set it to automatically use UTF-8 and include BOM mark on every new page I create.

In Eclipse/CFEclipse however there seems to be no choice for adding BOM marks in your pages. After a while of desperate Googling (this would be crucial if I'm to use CFEclipse as my editor) I came upon a workaround that seems to be working. Not surprisingly the solution was proposed by Paul Hastings.

The solution was found here, where Paul says "each of our coldfusion pages starts with: <cfprocessingdirective pageencoding="utf-8">"

So now I added ...

... to one of the pages containing Norwegian letters and it seems to work.

Now I hate the idea of having to add this to all pages we create, but if Paul Hastings is doing it, then it is probably not a bad idea anyway....

I never really thought of this before, but when calling a CF function I've always done something like this:

I just looked up queryNew() in cfQuickDocs (excelent site), and when I saw it done this way in the example, it got me thinking. We don't want any variable called "newRow" or "temp". So why bother, when the following works just as well:

Are there any pros or cons I am not aware of? Or is it just a personal preference?

As for now I think the last version is better in that it entails less typing, and I actually find it more readable.

What do you think?