Example usage:

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.

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?

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.

Since you asked, of course I'll show you an example right here. I will create a user gateway class [UsersGateway|+DNS;+User|+getUserBean();+getAllUsers()]:

You simply use an img tag with the source http://yuml.me/diagram/class/, the "scruffy" option makes the output look less formal.

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.

Another way to put it is this(model/securityService.cfc):

The business model gateway in this example would be something like(model/data/gateway/securityGateway.cfc):

Maybe because I'm not a seasoned OO veteran but I'm looking at this and trying to figure out the best course and can't decide which one to take. From the service cfc do I pass in the user object or it's properties (username & password)?

For now I'm passing the object's properties if the gateway method only requires data and doesn't need to access any of the objects other methods like setters. If the gateway method here needed to use the object's methods instead of just it's properties, then I'd pass the entire object. So what do you think is best practice?

I'm thinking that it's wrong to give a bank method to a user object. Maybe I've had too miny *hic* Red Bulls.

WTF, you may ask? Well, you know how when you submit a form to edit a user account for example, and then you have to pass all those form elements to your user bean object's getters and setters one by one. userObj.setUsername(form.username), userObj.setUserpassword(form.password) and so on.. well you can forget about ever doing this again.

HOW!?!? By using the Coldbox beanfactory populatebean method. You can play with form elements first if you need to, then simply call the populate method passing in the current userbean, and then Coldbox will match form elements to the bean's getter and do the heaving lifting for you returning an updated bean ready for saving.

2 simple lines, get bean and populate bean. Then do whatever else you prefer from there to save it wherever etc..

The most important thing to remember is that your actual bean cfc object must use an init method with setters. And the form element names should be the same as the bean names.

A bean's init:

So that:

Hope that helps. :)

Web Sequence Diagrams