MVC - Structured View Layer Development

Tue, 08 Sep 2009 11:05:00 -0700

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: <$cript type="text/javascript" src="#jsDir#ddlevelsmenu.js"> 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:



users = event.getValue('users');
listPerPage = getController().getSetting('listPerPage');
userDetailLink = "View Details";
catagory = event.getValue('catagory');




#catagory# readings


Always only $2.99 per minute!




...

After using view layering:


users = event.getValue('users');
listPerPage = getController().getSetting('listPerPage');
userDetailLink = "View Details";
catagory = event.getValue('catagory');
function wTitle(){
writeoutput("
#catagory# users

List of all users from the #catagory# catagory.


");
}




#wTitle()#


...

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.

Generating and using site documentation, cfcdoc
Sun, 06 Sep 2009 09:17:00 -0700
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?

Do ColdFusion programmers need to be object oriented gurus?
Fri, 04 Sep 2009 11:25:00 -0700
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.

ColdFusion OO, MVC, and Frameworks
Tue, 01 Sep 2009 16:19:00 -0700
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.

Consume object or object property
Sat, 20 Jun 2009 07:03:00 -0700
Here it is in a nutshell. I have a controller cfc in my framework that directs execution instructions to the business model cfc's. But I'm wandering if I should pass whole objects, like a user object, and get values as needed from it's methods within the business model? Or should I just pass the object's properties to the business model classes as needed?

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

instance.securityGateway.login(User.getUsername(),User.getUserpassword());

or

instance.securityGateway.login(User);


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




...


or



..



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?

CFC Method Testing in Coldbox
Wed, 20 May 2009 18:31:00 -0700
I got tired of trying to get cfUnit working and all I wanted to do was test component methods. I wanted to be able to simply point to it, test it, and enter arguments if required. And I wanted this set up somewhere easy I could use quickly, repeatedly, effortlessly, and painlessly (word?).

In almost all my applications I have a 'webmaster' directory where I run test. Lately I've found myself getting fancy with setting up a web development control panel of sorts. Whereas web sites generally have administration control for admin users, I've been building in webmaster control for developers. Mostly things like server and framework info, links to documentation, framework and site functionality examples, and etc.

Now I'm adding a little CFC Test form where I enter my cfc path, the method name, and arguments. It will pass the event argument so you can also test cfc handlers.

Warning, I just created this a few hours ago. It's tested to work but I haven't cleaned it up or put in validation and error handling yet.

views/webmaster/index.cfm (webmaster control panel)

	
	
	Enter Component Path:

	

	Enter Method to Test:

	

	Arguments:(comma seperated list)

	

	


events/webmaster/panelcontrol.cfc (Coldbox handler)

	
	
	
	
	
		
			
		
	
	
	
		//Display
		event.setValue("cfctestresults",ret);
		event.setValue("author","Clint Willard");
		event.setView("webmaster/dspCfcTestResult");
	

Basically it loops through the method arguments list you entered in the form setting them as part of the arguments struct. That arguments struct is then passed to the invoked component and method, along with the event object. Then the view is set to output with the test results, whatever the method is set to return.

views/webmaster/dspcfcTestResult.cfm

	cfcresult = event.getValue("cfctestresults","NA");


	#dump(cfcresult)#

KISS output.

Let me know if this might be a good idea to expand on or should I just LOL learn cfUnit? And the webmaster information and control panel stuff?

Coldbox Framework and Ajax: cfajaxproxy
Thu, 16 Oct 2008 08:19:00 -0700
After working in Coldbox for a while I know your first instinct is to make a cfajaxproxy call to a cfc event just like all the other Coldbox events. However, using cfajaxproxy is just a little different. Here is an example to show you one simple way of doing it, not the only way but one of them.

First let me note that I am using Coldspring version of IOC. It should work the same though with any form of IOC. Mostly we need the IOC to provide the bean to the services your Ajax call requires from within the Coldbox proxy.

After having provided a service in Coldspring like so:


  
    
  
  
    
  



we can use this "usersService" bean in the coldboxproxy.cfc like this:

	
		
		
		
		
	


The code above is what the Ajax, cfcajaxproxy, will call as a method for Coldbox to perform. It fetches a private message object bean, sets or updates some properties, then uses the gateway to save the object bean. I don't have a return or output but you can do that also here if desired. And here is the actual view and Ajax calling code:



#privateMessagesQuery.subject#

<$cript>
function showMessageDetails(messageid,read,subject,from,message){
	var e = new cbProxy();
	if(read == 0){
		e.setCallbackHandler(setPrivateMessageRead);
	    e.setErrorHandler(ajaxErrorHandler);
	    e.ajxSetPMRead(messageid);
	}
	document.getElementById('pmReply').style.display = "none";
	document.getElementById('pmDetails').style.display = "inline";
	document.getElementById('pmDetails_Subject').innerHTML=subject;
	document.getElementById('pmDetails_From').innerHTML=from;
	document.getElementById('pmDetails_Message').innerHTML=message;
}
var setPrivateMessageRead = function(res){
	alert('set to read');
}
var ajaxErrorHandler = function(statusCode, statusMsg){
	alert('Status: ' + statusCode + ', ' + statusMsg);
}


The cfc attribute is dot notation to the location of your coldboxproxy.cfc, mine here is at the root. Basically I'm showing the private message details in a div but needing to set the read flag in the database to 1 to indicate it has been read. And using Ajax I can set this in the database for each message read without a page refresh. The alerts in the javascript are for demonstration and testing purposes.

The code I provided is a cut down version of actual code and does not include the view event, form code, queries, or other behind the scenes code. I hope this helps to give you a step ahead on how to use Ajax with the Coldbox framework.

Create Coldbox plugin example
Fri, 06 Jun 2008 06:13:00 -0700
Coldbox plugins are a really useful aspect of the framework when you want to create reusable interfunctions. Interfunction is a term for a function within an application that can be used in any application within any one specific framework.

Coldbox plugin interfunctions are, to me, like UDFs, almost. Except that they are OO capable components. But enough with talk, read more about plugins here.

And here's an example of a custom plugin I created called "MyUtilities" that has a function utilizing CF8's new image resizing abilities. It's not expanded yet as this is just what I needed for the moment on a project.

This goes into a cfc (MyUtilities.cfc) file in your plugins directory, I called this plugin "MyUtilities" for now:

			
	
		
		
		
		
		
			if(IsImageFile("#arguments.fileLocation#")){
				myImage		= ImageNew(arguments.fileLocation);
				ImageSetAntialiasing(myImage,"on");
				ImageScaleToFit(myImage,arguments.xWidth,arguments.yHeight,"highestQuality");
				ImageWrite(myImage,arguments.destination,1);
				return ImageInfo(myImage);
			}else{
				return false;
			}
		
	
	


And this is how you'd use it in your code:
imageThumb = getPlugin("MyUtilities",true).resizeImage(fileLocation,thumbLocation,width,height);

You can see from the resizeImage function that I hard coded resize quality and antialiasing, as that is true anywhere in my project for all image sizing. But you can take this and customize it further for your needs. I just mostly wanted to share with you an example of using a custom Coldbox plugin.

Coldbox beanfactory populatebean method
Wed, 04 Jun 2008 19:20:00 -0700
I have to say I love this automatic bean population thing going around. Model-Glue does it also but since I mostly use Coldbox, that's what I'm showing here.

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..


		
		
		
			userBean = getPlugin("sessionstorage").getVar("User");
			getPlugin("beanFactory").populateBean(userBean);
			getUsersService().saveUser(userBean);
			getPlugin("sessionstorage").setVar("User",userBean);
		
		
		
	

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:

Matches:





Hope that helps. :)

ColdSpring ColdboxFactory: DSN and Mail settings
Mon, 26 May 2008 06:06:00 -0700
My second day into figuring out Coldbox, here's a little something cool. Putting it simply, using ColdSpring, in the CS.xml you can define a 'coldboxFactory' bean to use in creating other beans that define this factory's methods as beans also, then pass that bean into a class bean's property as a bean reference.

Actually, that doesn't sound simple as it is, so here's an example. Remember that I'm a newbie, so be nice.

coldbox.xml.cfm


	mail.urserver.com
	25
	username
	password



	

I've set mail settings and data source settings here in the main Coldbox config. I'll be using Coldspring for IoC and so I'll need to be able to pass this around in my beans.

Coldspring.xml


	
	
	
	
	   
	       DSNAlias
	   
	
			
	
		
			
        
		
			
        
	

This coldboxFactory has several methods that interface with the coldbox config file, among other things I'm sure. Check out the API for more info. But basically I create the coldboxFactory bean, then create other beans of the factory's methods. Then notice how I pass those beans into the handler beans by reference. These 'properties', as it turns out, are setters in the cfc, such as setDsnBean and setConfigBean. Then I just put them in variables for my other methods.

cfctest.cfc


	
		
		
	
	
	
		
		
	
	
	
		
		
	

Don't dis my cfc, I'm just playing around and testing stuff. Notice the setters that I mentioned before. If you do a dump/abort on these at run time you'll see what use they are.

general.cfc


	
	
	
	
	
		
	
	
	

And finally here's the handler that uses the IoC plugin I set in variables in the handler's init function that gets the bean set in Coldspring and runs the method that utilizes all the stuff we just went through. Check out Coldbox's Coldspring documentation for more information.

There are other factories to use I'm guessing and other factory methods within those. You can use all the methods in the coldbox.system.controller as beans also. But like I said, I'm just discovering this stuff right now. Frankly I need to think over wether or not passing bean reference properties to all my CS beans is the most effective way of using global configs any ways. Seems rather repetative as apposed to putting such things in a request scope through onRequestStart or something.

ini files with multiple sites - getProfileString
Sat, 29 Sep 2007 03:53:00 -0700
Its common now days to use an ini config file to set specific params for your site or application. An ini file is a plain file ending in an ini extension. You set params in a variable=value manner line by line, sometimes heading different sections with bracket enclosed headings (notice no space around ='s below):

example ini file (www.cfcdeveloper.com.ini)

[settings]
dsn=myDSN
mailserver=mymail.mailserver.com
mailusername=username
mailpassword=password
[other]
url=http://www.myurl.com
adminemail=myemail@myurl.com


Another good use for an ini file could be to duplicate an application or site across multiple domains and owners depending on the URL domain name, basically hosted on the same server. That way you can sell use of an application or site and maintain central control over the big picture. An update or new enhancement would populate all domains at once instead of having to duplicate the changes numerous times.

One way to do this is to name your ini file (this could be applied to CSS also) the same as the domain in which it is meant for. So I would name an ini file for my site www.cfcdeveloper.com.ini. Then if joebob.com wanted to use my site also, I could sell him the use of it and simply make another ini file named www.joebob.com.ini. Then when a visitor hits joebob's site, it will use his ini file instead of mine.

Something like this:

<cfset var iniFile="#getDirectoryFromPath(GetCurrentTemplatePath())#/#cgi.server_name#.ini">

So now the magic begins. We need to put these variables into a site wide scope to use everywhere. You can decide if you want to use application or request scope or something else. I like to use the request scope myself for smaller applications, application scope for specific other purposes and very large applications.

And here is the most simplified manner which I can show you how to do it (using the ini file above for example):














Hopefully that is all self explainatory above. Of course there are more efficient means to accomplish this also including using the getProfileSection function to fetch the sections and parse those out automatically. Look in the documentation to find the way you prefer. 

You can also use the setProfileString function to set values to ini variables if empty or other conditions. Or maybe set a default ini and use Application.cfc to set ini variables depending on the URL and such. There are many ways to use this power.

One other thing I want to show you about using ini files for sharing an application with many domains on one server. You can also make one ini file and give the sections names for the domain calling it. That domain would set variables depending on the section instead of the file name. Let me try to show you.

example (site.ini):

[cfcdeveloper]
sitename=cfcDeveloper
url=www.cfcdeveloper.com
dsn=cfcdsn
[joebob]
sitename=JoeBob
url=www.joebob.com
dsn=joedsn


Then you set the ini section before calling the ini to set variables to a site wide scope:

<cfset request.iniSection = "cfcdeveloper">

Something like this:









There are pros and cons to any style. Using sections for sites or domains, you have to add a new variable to all the sections one by one. But at least its in the same file. Using a file per domain, you have to open each one and add a new variable when one is added to the application. Pick whichever means suits you best.

Architectural Framework Woes
Thu, 16 Aug 2007 06:24:00 -0700
AHHHHHHHH! @#!$%#&%@!

Yeah, I'm a little aggravated this morning. I'm coding. It's not that I don't see the value of using MVC or any other type of framework, I hate to love them. A framework or any organized architecture, be it OO or whatever, is only as good or useful as the programmer who who knows it or uses it. Otherwise, its a nightmare to step into and have to debug or enhance if you've never been in it before. Its quit a learning curve that adds time to the whole process.

There are many frameworks and architectures out there now. Knowing as many as possible helps you to learn each one much faster. Then you pretty much become an architect developer or framework developer.

As my thoughts ramble on here I'm wondering if we programmers are creating such intricate and complexed patterns of doing something fairly simple is so that we can mask our work in a way that you must be skilled to read it and do it in any manner. Surely anyone can do spaghetti code, but break out the OO and the MVC and you've got a recipe for a lucrative highly skilled professional career. Books will and have been written about these ways of coding and now we can teach them in classes and give certifications in them.

Anyways, so I'm debuging an application this morning that I've never seen before. The application was developed in a framework I've never seen before either. I know many frameworks such as Fusebox, MachII, and Model-Glue, but this was different and proprietary. An error was being thrown that was not displaying the correct message and I needed to find the mechanism that handled the error and everything else. Without getting technical, I'm looking in 5 different files tracing back the entire path of the whole mechanism and getting frustrated. I'm sure I could come up with a much more shallow mess of code to do the same thing.

But here I am looking in controllers, facades, managers, components, config files, and everything else. It's worse than a maze, its more like a death maze. The further you get in, the harder it is to find the end, and theres no way out. At every turn you must remember all the steps you took up to now and all the steps you didn't take, as well as a riddle you read at every dead end, all without any way to write it down.

Ok, breath deep and relax. Is it too complicated? I don't mean is it too complicated for me to do. Of course I'll do my job and do it well. In fact, I really enjoy the challange and reward. But can we all get together and agree on something standard, for the sake of my sanity. Structural engineers build buildings and bridges with only a few differences between them. What works, works, and it keeps the structures from falling.

But this is all just wishful thinking from a crazed coder in a moment of despair. Non-programmers who think our job is easy would go mad to step inside our mind. The diversity of ways a coder can program is what drives technology to new heights and discoveries. I understand the nature of the beast and the importance of its complexity, I really do. Maybe more vacation time is the answer?

Creating an MVC ColdFusion OOP Application - Part 3
Fri, 30 Mar 2007 21:08:00 -0700
Part 2

Welcome to part 3, setting up the ColdFusion Server and MySQL database on your Windows PC, also called setting up your development environment. I'm hesitant about including this in my series because it has been discussed and taught just about everywhere. But mostly where I see a tutorial, each time it's a little different. So I thought it would be best to tell and show you how I set my development server up just in case your following along and suddenly something doesn't work right, you come here and see if the problem might be server related, maybe some step in the set up you did different than me. Unfortunately however, not all PC's are the same and there is the off chance that someone will have problems beyond my ability to help. There's one part in particular with my set up that took me 3 days to troubleshoot to get it working, luckily I wrote about it in my blog some time back, so now it's just part of the process. Hey, no one said programming was easy, it takes patience and determination.

While we're on the subject of setting up the development environment let's discuss some other tools you'll need if you don't have them already. Pick these up after setting up your development environment. This includes an IDE (integrated development environment) such as Dreamweaver like I use or anything else you can write and save files with, even Notepad. If you can't get Dreamweaver I suggest Eclipse with the CFEclipse ColdFusion plugin, it's free and very powerful. There's even an Eclipse SQL Explorer plugin, which I haven't tried but you might need later also.

Speaking of an SQL explorer, you'll need an interface to your MySQL data server when it's set up so you can actually create and manage databases and tables. If you'd rather use MSSQL data server instead of MySQL, please do so, but I'm not telling about that here. I use MSSQL at work with the MSSQL Management Studio and love it. For MySQL however, I love using Premiumsoft's Navicat tool, which I paid about $100 for. But if you want something for free, use phpMyAdmin, which we will be installing anyways, so just hang on.

Ok, so lets get busy installing something. First lets get ColdFusion installed. ColdFusion comes free as a developer edition which is full featured. The only thing different from the $X,000 version is that the free version only allows about 10 or so connections per server. Download the free ColdFusion MX 7 developer edition from here. You'll need to sign up for a membership to get a username and password. The download is 281 MB, luckily I have an 8Mbps cable connection and it only take me about 45 seconds to download.

Now, double click the installer and follow the directions, this part will take about 10-15 minutes total. Use the defaults everywhere but choose the J2EE configuration (ColdFusion with JRUN 4) in step 4 and choose Built in web server in step 7. Here's a good place to see screenshots of the installation and the steps: http://www.quackit.com/coldfusion/tutorial/coldfusion_mx_installation_guide.cfm

At the end of the installation you'll have a new directory under your C drive named JRun4. Your web sites will go under the C:/JRun4/servers/ directory which we will create when we get to that point. You should also be able to browse to the default installed web site at http://localhost:8300/ in your browser. Which will show nothing except two folders to your docs and CFIDE, more on that later. For now, just check that these two things are true or else uninstall and start over till you get it right.

Now lets get your MySQL data server installed, which happens to be easier than ColdFusion installation. We will be using a 4 in 1 application installer that will also be installing an Apache web server, MySQL data server, and the PHP server parser. With this installation you be able to do two things, develop PHP web sites if you want, and use the phpMyAdmin to manage your data server if you need it. If however you don't want all that and will be using another SQL manager, you could just go to the MySQL web site to download and install their single free product. The 4 in 1 installer is also free, called a WAMP, the best one that I use is here, it's only about 17 MB. Download then double click to install. The installer is extremely easy and fast, even a 5 year old could do it, so I'll just leave this to you. Once complete you will be able to browse to http://localhost/ where you'll see the WAMP welcome page and some links. One of the links is to the phpMyAdmin tool. The phpMyAdmin may need some config work to get working, if so just ask and I'll comment back the help you need.

By the way, http://localhost/ and http://localhost:8300/ is completely different. With the Apache server install you basically have two separate servers now. One is an Apache PHP server and the other is a J2EE ColdFusion server. Notice we didn't use Windows IIS server at all, don't use it.

Now you have the ColdFusion developer server up and the MySQL server up and we'll be using these two together to create powerful apps. Just leave it at that for now and we'll configure the rest when we're ready to set up our web app. Then I'll tell you a little more about the ColdFusion server and Jrun and show you about creating instances and why.

Oh, almost forgot about another important tool. The image editor. I use Fireworks for layout and gif creations. Then I'll use Photoshop for complexed jpg photos and then I might use Illustrator for logos and some illustrations. It's controversial as to which is best for what purposes and why, but I always say that the tool is only as good as the person using it, so decide for yourself which you like and want to use for whatever purpose. If your good at one of them and feel good using it, then use it. As for free image editors, there aren't very many good ones if any at all. I've never used a free one before but I hear that Gimp is good, but I've never used it.

So go get some tools, play around with them and I'll see you in the next part of this series where we'll talk about gathering requirements for our application. This would be the part where you meet with the client or your boss and discuss the project in detail.

RIA CFML Flex Flash

GraniteDS for Flex 3 and Glassfish

Adobe Misses Flex Boat

MVC - Structured View Layer Development

Generating and using site documentation, cfcdoc

Do ColdFusion programmers need to be object oriented gurus?

ColdFusion OO, MVC, and Frameworks

Consume object or object property

CFC Method Testing in Coldbox

Coldbox Framework and Ajax: cfajaxproxy

Create Coldbox plugin example

Coldbox beanfactory populatebean method

ColdSpring ColdboxFactory: DSN and Mail settings

ini files with multiple sites - getProfileString

Architectural Framework Woes

Creating an MVC ColdFusion OOP Application - Part 3