It took me a day to figure this out, live and learn right. I used 'do' as the event name in one of my Coldbox applications as opposed to 'event' given as the default. If you're considering what to name your events in Coldbox, don't. Just use the default 'event' name given. I was just trying to be unique but it backfired.

The 'do' term is a reserved keyword in Flex, ActionScript actually. The lesson I got from this is to not ever use any keywords from any language for which you may mix. In this case I was using Flash remoting from my Flex application to to fire remote ColdFusion functions from the Coldbox framework remote proxy.

Here is the code I was using in my Flex actionscript. Notice the 'event' object param passed to the proxy process function, you can't use 'do', well technically you can but don't because it won't work.

I didn't know until now about the replace function in MySQL. Evidently you can do case-sensitive search and replace pretty easily.

update table set field = replace(field,'before','after');

I'm not sure about using regex but you can do multiple fields at once. Like this:

update tblblogentries set body = replace(body,'ColdFusion','ColdFusion'), title=replace(title,'ColdFusion','ColdFusion')

Don't even say it ;p

I had a situation where I wanted to pass a query param to a ColdFusion page that would use it to find a record in a cfquery then pass that record to a Javascript function used to display that record in that ColdFusion page. Thats a lot to say all at once. Let me see if I can explain it better.

My ColdFusion page displays a list of private messages for a user in their user account. This list is at the top of the page and shows date, time, sender, and subject. When the user clicks on the subject of any message in the list, Javascript Ajax is used to fetch the message details from a component and display the message fully below the list, kind of like an email program. Also when the page loads, as a default the first message in the list is automatically passed to that Javascript Ajax and displayed. That's easy enough so far.

It gets more complicated when you allow that same page to be passed a URL query param equalling a message id you want specifically to be shown first, instead of just the first row in the query. It's hard to explain but try to follow me. It's not my intention to explain everything like a tutorial so here's the code I implimented to solve my issue.

The page would be called like so, http://www.site.com/showPrivateMessages.cfm?privatemessageid=2435. But remember that the page can be called without the URL param, in which case it would just use the first record in the query of private messages. Including the param would tell the page to display that particular message's details first.

So on the called page I get my private messages query: privateMessagesQuery = event.getValue('privateMessagesQuery'); (I'm using the Coldbox framework)

Set up the param to use with a default of 0: privatemessageid = event.getValue("privatemessageid","0");

Then I need to define which row in the record matches the one I want, but I must set this up first: rowtouse = 0;

Now I need to recurse through the query in a loop to set the rowtouse variable equal to the row found for the id:

Ad now in my Javascript I want to use that row number to set some variables to use in a function call that displays the message details for the message who's id matches that passed in the URL param. I'm not showing the function that does the actual displaying of details, just the function name for time and space's sake (I'm busy).

The showMessageDetails just sets values in span tags, DHTML Ajax stuff. Any ways, you can see here how I'm using ColdFusion inside of Javascript to use back in ColdFusion, or HTML to be technically correct.

Once apon a time, and still only if I must, I used the 's onLoad attribute to call a Javascript function after a page loaded. I no longer follow that pattern opting instead to use a window DOM method, window.onload, also called a global event handler.

Here is an example of calling a Javascript function on page load in the script block.

It sets the cursor focus to a selected field in my form on page load.

And I found this cool resource while looking around, it's a book: Structure and Interpretation of Computer Programs or SICP. What does that have to do with this you ask? Well if you need something like the following example of a complexed javascript onload, it might come in handy.

Is it me or is the view layer in the MVC pattern being ignored or at least understated? Working on my most recent project I stepped up my MVC and OO emphasis during development and noticed that we, web developers, aren't doing anything structured as far as view development goes, at least I can't find anything searching the net. We conform the underlying complexities, like the model layer, into formal design and standards (OO for instance) but don't hold the view to the same or comparable expectations. We make sure that the view layer is seperated from business logic at the layer level but when it all comes together at the view level we fail to make anything formal out of that. I'm attempting here to formalize and structure my view layer borrowing my experience in MVC and OO methodologies. It may be done already somewhere else but I can't find it and I need it, so here it is, right or wrong it's a jumping point.

If you look at the view layer in an object oriented approach and formalize the views as pseudo classes you may be able to deduce where I'm headed. For example, views or pages have properties and methods that can be used to create UML class diagrams during the design phase. In addition you can carry these through the implimentation phase and realize the seperation within your page view code. The view is more than just the HTML layout of tables and div tags where content sits, it's a layer, not just a file. We already seperate CSS, Javascript, and other like concerns but not the inner page code structure, and I'm not just refering to physical speration. It's just assumed that by the time you get to the actual view programming that you'll be able to just do it, no planning or formal organization required.

I'm not talking about architecting the view in an object oriented manner, that's just too much. I believe the view can benefit from organized structuring of page concern seperation and we want to use this technique in planning and in coding. To demonstrate this I'm going to create a simple and quick fictitous site with a few views in an MVC structured application.

Here's a draft of a UML class diagram showing how I might plan my views and view layers on paper. Notice that my page views are now represented as classes with properties and methods. Keep in mind that UML diagrams and planning is an iterative process and will change quite frequently but, we must start somewhere.

Notice first the hirarchy from Application through layout and to individual nested pages. These are connected to show how each page view inherits it's elements from upper view layers. I'm not advocating that this is the right way to diagram or think of it, just my way for now.

The application node is the top node here and has properties and methods you should recognize. This sits in the view layer in an inner application layer. An application layer in my mind can also include other nodes like UDF and configuration files.

Inner view layers:

    Container layer - the top most containing layer surrounding all other inner view layers in an application. All other view layers inherit from the application layer.     HTML layer - Defines containers and layout structures in which to place content.     Content layer - Contains the content of page views and any externally viewable content media they may include.

My site has a default_layout page that displays content layers, and as usual frequently repeated elements across multiple views are located here too; ie the header, footer, and navigation. Notice it's properties here. The value for jsDir will be the physical path that will be used in the source attribute of a script tag or anywhere else we may find a need for it. For example:

The homeLink property has a value equal to the actual href tag, the link back to the home page. And in this property we can edit the link as needed from one easy to find location in this view. The default layout view here also composes of the CSS, the JavaScripts, and anything else you would need to include somehow. These inclusions, not expanded here, could be psuedo classes with properties and methods as well.

Moving down the view layer we have the content layer view nodes which is the meat of our site to the user. They inherit properties and methods of the layout layer as well as defining their own. In this diagram we can see what the content views inherit, most useful when trying to remember what your content view pages are capable of before any code goes into it.

Starting with the home content view I created a userListLink property containing the href link to the userList content view. That property can be used anywhere in the home content view.

Next, the userList content view will output a list of users that we retrieved from the control layer after being queried and cast to an array in the model layer. So the users array will be a property of array type. Notice I don't type simple properties such as strings. There are two other properties, listPerPage (how many to paginate per page), and userDetailLink which is the href for the link to the userDetail content view. Here we also have methods for this view.

The userCountTotal() function placed here for example is a simple function the view can call from anywhere to get a value. And no matter where or how many times this function is placed it can be altered from one location.

Let's take for example the next function, wTitle(), to see how this works in practical code. The purpose of this function is to encapsulate a piece of content and seperate it from the views tables and divs, making the design much easy to read, move around, and format. The best way to show this is probably a before and after example.

Before using view layering:

After using view layering:

Notice how we took out a huge chunk of content making the layout much easier to conceptualize and edit. This also lends to seperating concerns for content programmers and design layout artist. In making these separate I usually rule out any chunks that are either small or contain more layout code such as td repeaters. All I want to be left with below the content functions is basically a skeleton of table and div tags.

The userDetail content layer view has two properties. User is a user object passed in from the controller and the userListLink is an href string used to link back to the userList node. There are two functions used to output content, wUserImage() is the code to output the image for the user. The wUserDescription() function is called to format and place the description block how and where you would like. Think of these functions as an easy way for a layout artist to place content within his work that the content programmer has already developed. These functions could also take in arguments if the programmer feels witty. Then a view layer API can be documented and used by the design artist.

What I'm doing inside the views to seperate content and layout design isn't as important as the benifits realized from the view layer model in the design phase. The other models such as those in the model layer can now be associated with nodes in the view layer. Eventually I want to produce a document where every element that is a part of the process can be modeled to and from each other and between layers in a world view type map.

It's all pretty simple and not well thought out for now, the result of about a day of thinking. I do plan to expand it if I can't find anything comparable out there. For now it seems to help me a lot with organizing and visualizing page views. Esspecially when you consider that I'm already thinking this way for the other layers.

I'm completely embarrased to admit it but, I didn't know until yesterday that not only can I create my own web site's API documentation automatically but how useful it can be. Sure beats glazing over my directories and trying to remember where everything is and what it does.

My latest project has got me dealing heavily with application API's and it's important to read and understand how to apply the API to development, especially when using OO framework architectures. Reading and using the API's for my Coldbox framework (here) I got to thinking that having this documentation for my own site would be very useful and very cool. It literally puts OO into perspective, for me anyways since I like the API's, and helps me to visualize how my classes (components) are organized, if anything is out of place, and if I can optimize anything.

At first I was using the CFIDE component utilities (localhost:8300/cfide/componentutils/) like the explorer and the componentdoc. But it would always list packages from everywhere, including the CFIDE and WEB-INF folders. And then it would list the pakages from the mappings as well as the folder it pointed to. So I edited the code to exclude folders, thinking that there's got to be a better way, and there was. Looking back at Coldbox's API I notice it's from an open source RIAforge thing, get it here: CFCDoc. It's so easy, just extract the zip to your root under a folder, like '/api/' and go there. There's information about what to do next because all the packages you'll see at first are the one's in the /api/ folder you placed it in, not very useful. But basically you add or delete folders to include through a simple config xml file and that's it, your exploring your very own API.

Depending on the length you want to go to in your documentation you can go really wild with component and function attributes like hint and displayname, probably more too. Using these extra attributes I'm sure you thought were useless and time consuming you can add enough information to make the API a virtual users manual. At the very least you can use the API to match up with your UML class models. I'm thinking also that planning a site's structure could be done API style instead of UML style, maybe even faster. You can think of what classes you need and how to package them for your application doing API visualization. In other words, what should your API look like and is it all packaged logically from an API documentation perspective?

Before I begin let me just say that although I'm not a certified Java developer, which would make me an automatic OO guru, I do develop Flash and Flex applications using AS3, which is an OO language. Yes, when it comes to OO I know what I'm talking about and have studied and used patterns for a few years. I'm not a pure OOist but who is and who really needs to be?

I'm so tired of chasing that alusive brass CFOOP ring of knowledge, trying to become a an object oriented guru with the deepest depths of understanding. I'm already there and so are you, seriously, its not as far as you thought. And I'm talking to CF verterans that use cfc's as objects, and patterns (whether they know it or not) to solve problems. You may not be using pure OO but you are OOing purely enough. For those reading this that know nothing of OO please stop and go read a few beginner OO basic articles and then come back.

There's only about a 10% difference between OO in an "OO language" like Java, and OO in the ColdFusion scripting language. And that 10% difference is used about 1% of the time. So you can't create interfaces (technically you can with underlying Java), big deal, and completely irrelevant too. Creating "I" classes is simply rewriting the original class in a more impressive way and there's only a 1% chance you'll actually need the real thing. Interfaces for the most part are for compile time error checking and CF is not a compile time language, not at our level it isn't.

Let's see, what else is there that I'll probably never have a need for, or can do in some other CF way. Overloading, constructors, overriding, and multiple inheritance, and that's about it. As for the constructor, we use an init function on object instantiation as a consturctor for now but, CF 9 will have implicit constructors. Overriding can be accomplished in CF using composition. BTW, implicit getters and setters will be available in CF 9 also.

Other than the lack of multiple inheritence (which isn't a requirement to be considered a true 'OO capable' language, like Java and Smalltalk), if Adobe added overloading capabilities then CFers could be concidered OOers too. And just like a Java coder can produce crappy non-OO code so can a CF coder create crappy non-OO CF code.

Here's the thing though, follow me. ColdFusion is a RAD tool that can be structured in an OO way following proper OO techniques. ColdFusion is OO when and if you need it to be but we certainly don't want it to be totally and purely OO, ever, EVER. If you make it pure OO say goodbye to rapid development and say goodbye to the market it is ment for. OO was devised to help solve complexed problems in very large systems, something that CF can but doesn't do much of. Those complexed and very large systems are far and few between, the market is in the average system, which don't need OO much any ways.

All that being said, if you've got the jest of OO terminology down and have enough understanding of the underlying principles that you can apply it safely, stop worrying about it and get back to work. The only way you can become a better OOer is to practise it. And as for those Java guys laughing at us CFers when OO is mentioned, they're just trying to chase away the new kids in their OO sandbox, spoiled sports don't want to share the spotlight. Honestly I don't consider anyone an OO programmer based on the language he uses, it's how he uses the language that defines a programmers OO understanding. And if people will stop refering to CF as it was prior to the MX version we'de stop having this debate in the first place. Once apon a time, ColdFusion couldn't be architectured with OO principles, but now it can. The end.

Saying that you don't need OO or MVC to build a ColdFusion application or web site is like saying you don't need blueprints and building code standards to build a skyscraper or a house. Granted, blueprints are overkill for a birdhouse but, OO and frameworks are overkill for a one product web site too. You should know when all the overhead is needed and when it is just going to be overhead. To me, it seems like this is the real problem when it comes to utilizing more sophisticated coding techniques rather than just plain old coding.

In all actuality most of the complaints, confusion, and questions come from weekend programmers who don't need to concern him or herself with such extremes. But they make a mountain out of a mole hill (or an application out of a web site in this case) because they want to hunt with the big dogs or think they need to or should, or they just feel inadaquite if they don't. I don't blame them, I did too, and I wouldn't be where I am today if I didn't venture into the world of software engineering. But all that stuff didn't add anything positive to my low level projects at the time except taking more time to do it, so be careful.

Here's the honest to goodness truth about using all that fancy stuff. Any site or application created using any of that overhead can be created just as well with straight down proceedural coding. The end user, and sometimes even the client wouldn't know the difference between one and the other unless you pointed it out and showed them. In all frankness, only about a quarter of web sites need to bother with anything more than simple code, yet three quarters of web developers think they should.

My advice to web development noobs is to stick with the one thing you need to get the job done unless and until that job requires more than what that language can do efficiantly on it's own. Who knows, you might develop a simple site that makes you a millionaire without ever knowing what OO is. But if that site begins to grow unwieldly with errors coming from nowhere, it's time to turn to more sophisticated techniques. It's time to use MVC, properly incorporate a framework, and maybe even learn some OO terms and patterns. Then the question "when should I use the fancy stuff" becomes "how, what, and where do I use these".

Personally I use an MVC architecture on anything over a dozen pages, frameworks on anything with more than a few applications, and OOD/P on anything considered an enterprise. If you must, its important that you be able to do these things with professional precision to get something out of it. Your not going to get any ROI using a framework on any application if you've never used one before, so don't practice where your paycheck comes from.

MVC is a term used to describe a seperation of concerns, the business model, the user interface, and the central controller. It's not a product and there is no one right way to do it. As long as the thinking is done in one place, the displaying done in another, and neither knows about the other except through a controller, your using proper MVC architecture. Pretty simple right? If you only have a few events, or page views, then yes it is.

But, try rolling your own MVC on a medium size project and you'll grow to appreciate frameworks rather quickly. A framework is basically an MVC, structured and expanded for medium to large scale projects. That is, it supports agile development by not only insuring best practise MVC organization, but also offers commonly used programming logic in prebuilt API's. It's the foundation or base that will be the strongest part of your structured application if used properly.

Object oriented programming basically helps when you can objectify parts of a program into seperate entities and only if there will be a lot of them. In addition it's only benificial if those parts will be very active during the life of the application. By active I don't mean the use of the application, I'm talking about moving things around, enhancing them and depricating them, or allowing others to use them. If an object is going to be static in that regard, then it shouldn't be factored into the decision to use OO.

In summary, something important to think about while you hone your enterprise software engineering skills is that, as you get more comfortable with this sophisticated stuff you'll become more able to use those bigger skill sets on smaller scales. I for one find myself able to flesh out an OO UML model for a simple site in a matter of minutes. An OO noob might waste valuable precious days over the same thought with a negative ROI. So yes, you can use this stuff on smaller scales effectively when it becomes second nature and you don't have to think about how but what. As for all those naysayers that are swimming against the industry tide and trying to convince you that it's all uneccessary, they couldn't be more wrong. The storm is coming, mark my word. Maybe not in our life time but soon, developing web sites will be out of the range for the average Joe and the strongest of proceedural coders will be lost without keeping up. Stop pouting and start evolving, accept it, embrace it, love it.

All of my sites are hosted by Crystaltech.com's ColdFusion plans and I've always been on top asking for the next CF version before they've gotten it. This time they have beaten me to the punch, offering the new CF 9 in beta for testing before I knew it was out myself, too busy to notice I guess. Hurray for Crystal Tech! Are they the first this time? Here's the email:

Dear Customer, ColdFusion 9 Beta plans are now available!

This latest iteration from Adobe includes many exciting new features and improvements that will make your life easier, including:

Adobe's first ever ColdFusion IDE, ColdFusion® Builder™

Better application performance with more granular control over code, templates, and applications

Language and database enhancements

And much more

After ordering your FREE Beta Plan, please share your thoughts in our CF9 Beta public forums. As one of the first developers to test-drive CF9 in a full-featured hosting environment, we'll be anxious to hear what you like as well as what needs improvement. We're thrilled to be the first host fully backed by Adobe to offer CF9 Beta, and hope you're as eager to experience it as we are to offer it. Please let your colleagues and other industry contacts know - in fact, feel free to tweet it from the virtual rooftops. Simply click the link below, login to your Twitter account, and either use the embedded message or create your own.

**Please note that the beta plan is only available on new site orders made at http://www.crystaltech.com/coldfusion9.aspx. The free beta is not available for existing site upgrades.

Happy Test-Driving! -The CrystalTech Team

Just got around to getting my captcha added to the comments entry for my blog. After about a year, of the 7500+ comments in my database only about 50 were legit! Finally had to make the upgrade when a spammer used it to do something really bad and my hosting provider delete my comments file. Well, cleaned out and ready to go again, sorry to those who got spammed by subscription notification emails, fixed now.

Here's the code I added to make it happen. Thanks to Ray Camden's blog about how to do it, or as I call "copy and paste help ;)".

The hash stuff is to make sure the spambot doesn't do a simple search for the actual captcha text in the hidden form and use it. In simple terms, you need the actual captcha text in a hidden field for validation on submit but you don't want anything to be able to read it except your script, so you hash it then unhash it.