software design and other stuff

Class File PHP

2011-12-14T11:55:00.000-08:00

I sent a few hours and came up with a Class file that would represent my counter:

id = $id;

//get recs from db
$rec = $this->getRec();
$totalCount = $this->getCounterTotal();

//update instance vars
$this->counterName = $rec->name;
$this->counterValue = $totalCount;
}

private function getRec(){

$rec = mysql_query("
SELECT id, name
FROM tablename
WHERE id = $this->id
");

return mysql_fetch_object($rec);
}

private function getCounterTotal(){
//select and count recs equal to id
$rec = mysql_query("
SELECT COUNT(id) AS count, date
FROM tablename
WHERE counterid = $this->id AND active
");

$row = mysql_fetch_object($rec);
return $row->count;
}

// accessors
public function getCounterName() {
return $this->counterName;
}

public function getCounterValue() {
return $this->counterValue;
}

//mutators
public function incrementCounter() {

//update db
mysql_query("
INSERT INTO tablename
(counterid)
VALUES
($this->id)
");

//var_dump($this->id);
//break;

}

public function resetCounter(){
//get recs for the counterid
mysql_query("
UPDATE tablename
SET active = 0
WHERE counterid = $this->id
");

//var_dump($this->id);
//break;
}

public function getAllRecs(){
$recs = mysql_query("
SELECT c.name AS name, a.date AS date, a.schoolid AS schoolID, a.active AS active

FROM tablename a
join tablename c on c.id = a.counterid

ORDER BY date DESC
");

return $recs;
}

}

?>

While building my class file, I used a test.php file along with it to test it. A common practice when building bus. classes. Once the class was complete, I completed the DB table.

I ended up creating two tables:

tablename
tablename_associations

The tablename includes an id and a name for the counter.

Most of the data storage is in the associations table, where i am storing the id, the date of the request and a boolean col representing if the col is active in the current count, since it can be reset.

Next, I build an administration page that would allow whoever we gave access to it to reset each of the counters. Also on the admin. page is a report of each of the requested counts: see below

Now came the trickiest part of all. The problem I ran into next, was my new learning of the week. When using AJAX, which is essentially the XMLHTTPRequest object , that you CAN NOT remotely call a page on another server. This is know as the same server policy. This was a big problem since the server that was serving up the counter requests was NOT THE SAME as the server that was hosting the class(s) and db that were storing the counter. I had no way to reconcile this since I did not own the client server, only the serving server.

Hmmmm, what to do next??

This post got me started to what my option would be, which was basically two

1 - create or use a proxy server to fool the client and server into thinking they were the same domain
2 - use a different javascript notation called JSON, that would allow you to inject a script.

Neither of these options seems too trivial, after about a day of reading up on the two, i choose option 2., JSON.

Here is the JSON enabled call from the client side:

function getCounterJSON(param){
$.getJSON('http://domainName/path/view.php?callback=?','counter=' + param ,function(res){
document.getElementById(param).innerHTML = '&nbsp&nbsp&nbsp' + res.counterValue + ' views';
});

}

Here is the view.php page and its callback function.

//VERY sneaky JSON javascript object notation callback function - working around the security *blocks when ajaxing from one domain to another - which is illegal.
{
echo $_GET['callback'] . '(' . "{'counterValue' : $counterValue}" . ')';
}

Here is the rest of the view.php page preceding the callback function.

//CounterBase creates the objects $marks, $attendance, $progress
include_once 'CounterBase.php';

//check to see if someone is requesting to update a specific counter
$counter = $_GET['counter'];
$counterValue = 0;

//var_dump($_GET['counter']);
//break;

if ($counter == 'marks') {
$counterValue = $marks->getCounterValue();
}elseif($counter == 'attendance'){
$counterValue = $attendance->getCounterValue();
}elseif($counter == 'progress'){
$counterValue = $progress->getCounterValue();
}

counters, javascript, JSON and PHP

2011-12-14T10:55:00.000-08:00

I have a customer that forwarded me an email that said "can we create counters on our web page?" My first thought was, its not the 90's, people don't use counters anymore. So I did a little research, about 5 minutes, and found a couple web sites that create counters for you. Like this one and this one. I send a email back with links to these sites and said something like, its pretty easy.

Then I got an email from my boss who said, "James, I think they want you to do it for them". So, I spent about 1/2 hr and documented the steps necessary to create a counter using one of the two sites, mailed the steps to my customer and waited. Here is a copy of my email with the steps:

Ellie, follow these steps for each page you want to insert the counter code on.

go to e-zeeinternet.com site

1 - enter the page URL, like https://siteURL , into the Page Counter that it will be placed on:

2 - choose Numbers of digits to show

3 - Choose pageviews

4 - Choose No, twice

5 - Select the counter style you prefer

6 - scroll to bottom of page, click Get Counter Code

7 - copy the contents from the box

8 - using an html editor, open the page specified in step 1

9 - paste the code into the location where you want counter to appear

10 - save the page

11 - reload the page and you should see the counter

you can edit the code a bit, to remove the text, for example.

I tested out on an html page on this end and works fine.

james

Next, I got an email from a guy down the hall who supports this customer I had just emailed. She emailed her contact, the guy down the hall, when she received this message from me.

Toby, the guy down the hall, said "james, i tried doing something like this before, but i don't know where to put the code. the plot thickens"...

Once I spoke with Toby further, I found out that the customer wants to track the # of times 3 specific links are clicked in their existing system. After clarifying a couple other issues, Toby gave me access to his test server and away I went back to my corner of the world to see about creating counters for the 3 links.

I googled a bit for "creating web counters" and found almost all javascript solutions, many of which used cookies to store information for a user. Cookies was a good solution, at least initially. You can see the alert() in the functions as debugging options. This was enjoyable, tinkering around in javascript until I got the code working.

Javascript Cookies

The basic premise of the cookie is a way for the browser to remember or persist information about the user when they come to a web page. Great, perfect, if the requirement was for user to keep their own counters.

Three requirements I was solving:

1 - adding a call to the incrementCookieCount function when the user clicked on a specific link.
2 - call the getCookieCount function for the 3 links requested, outputting the value of the cookie next to the link.
3 - creating a link that would allow the user to reset the cookie count, when they wanted. This would basically delete the cookie and recreate it, setting its count back to 1.

This was great, all this counting and incrementing and displaying and resetting was just fun, and I was able to do it all right in the client side browser. I was very proud once I got everything working. I showed my customer, he was excited bla bla...

Here is how I was calling the increment function:

if(data_type == 2){
//alert('attendance ' + data_type);
incrementCookieCount('attendance');
}else if(data_type == 3){
incrementCookieCount('marks');
}else if(data_type == 8){
incrementCookieCount('progress');
}

Here is how I was displaying the count:

getCookieCount('progress');

Here are the functions:

function incrementCookieCount(cookieName){
//alert('');
var count = GetCookie(cookieName)
if(count == null) {
SetCookie(cookieName,'1')
return 1
}else{
var newcount = parseInt(count) + 1;
DeleteCookie(cookieName)
SetCookie(cookieName,newcount,exp)
return count
}
}

function getCookieCount(cookieName){
//alert('');
var count = GetCookie(cookieName)
if(count == null) {
SetCookie(cookieName,'1')
return 1
}else{
var newcount = parseInt(count);
DeleteCookie(cookieName)
SetCookie(cookieName,newcount,exp)
return count
}
}

//these are like private functions, not called directly by the client.

function GetCookie (name) {
var arg = name + "=";
var alen = arg.length;
var clen = document.cookie.length;
var i = 0;

while (i < clen) {
var j = i + alen;
if (document.cookie.substring(i, j) == arg)
return getCookieVal (j);
i = document.cookie.indexOf(" ", i) + 1;
if (i == 0) break;
}
return null;
}

function SetCookie (name, value) {
var argv = SetCookie.arguments;
var argc = SetCookie.arguments.length;
var expires = (argc > 2) ? argv[2] : null;
var path = (argc > 3) ? argv[3] : null;
var domain = (argc > 4) ? argv[4] : null;
var secure = (argc > 5) ? argv[5] : false;
document.cookie = name + "=" + escape (value) +
((expires == null) ? "" : ("; expires=" + expires.toGMTString())) +
((path == null) ? "" : ("; path=" + path)) +
((domain == null) ? "" : ("; domain=" + domain)) +
((secure == true) ? "; secure" : "");
}

var expDays = 30;
var exp = new Date();
exp.setTime(exp.getTime() + (expDays*24*60*60*1000));

function DeleteCookie (name) {
var exp = new Date();
exp.setTime (exp.getTime() - 1);
var cval = GetCookie (name);
document.cookie = name + "=" + cval + "; expires=" + exp.toGMTString();
}

function resetCookie(param) {
//alert('resetting cookie... ');
//var name = "marks";
var exp = new Date();
exp.setTime (exp.getTime() - 1);
var cval = GetCookie (param);
document.cookie = param + "=" + cval + "; expires=" + exp.toGMTString();
}

function getCookieVal(offset) {
var endstr = document.cookie.indexOf (";", offset);
if (endstr == -1)
endstr = document.cookie.length;
return unescape(document.cookie.substring(offset, endstr));
}

This is what the web page looked like with my code in place:

This is what the output looked like from the web page.

When I checked the layout in another browser, it hit me, that the solution I had created was not the one being asked for. This solution would give every user in each unique browser their own counters. What I needed was a solution that would persist outside of any browser and user.

I would need a server side solution, and a database that would store the counter information, persist and read/reset. Hmmmmm

I turned toward PHP, since I had a PHP server available and a mySQL database that could store the data.

Step one: Create a class that would represent the counter, using PHP.

Step two: Build a persistence mechanism for the counter data.

Step three: Modify the javascript to read PHP class file(s).

Step four: Use an AJAX technique to call the counter update and increment functions, while outputting their results in the html page. This would be tricky, but I had done similar things using AJAX and Jquery in the past.

Continued in next post.....

OOP, Beans, Gateways, Services

2009-10-08T12:02:00.000-07:00

Today - i went into a very old part of an application and revised some very old bus. logic. I am giving a facelift to part of a web site and while looking at a view page decided i would change a little logic. There was a call to the database in one of the view pages, since the beans being served up via the application to the view did not have all the data needed. This is a little lazy, to put a call to the db in a view, but understandable, especially if you do not have alot of background in MVC, Gateway, DAO, Front end controller design patterns, not to mention OOP.

After of a bit of consternation about what to do and finding another place in a related view file where i needed a bit more data, i decided to do it right. That meant going into the domain and finding the bean and dao responsible for getting and setting the data for the bean.

First, i needed to be sure i could add the little "bits" of data needed before adding them to the bean and dao. The data i wanted to add was from another database on the same server. No server linking needed! I spent a few minutes looking up how to do this and added the code to the read function of the dao that joined the existing table to a new one in onther db.

Next i added the getter and setter methods to the bean, reloaded the controller - since they cache my beans (since im using Coldspring and machii) - a couple MVC / oop frameworks.

Finally, i added the call to the new bit of data now being server up by the bean and whalla - im in busniess - logic all where it should be.

amen

object programming coldfusion

2009-09-02T10:58:00.000-07:00

I just spend about 3 hrs trying to figure out where a piece of output was coming from. This is a bit of a rant against object oriented programming, at least in CF. First off, the resome i was looking for this piece of code is to analyze a program area in the application. For some users, who have alot of data, this list that is build and displayed to the user takes way too long to build. Sometimes in excess of 60 seconds. I think it has caused us to change the loop time out setting in the administrator.

This application is build in a framework called machii. Machii is capable enough framework, a bit heavy, meaning a lot of overhead and files that comprise the framework. Machii makes it easy enought to know where to begin looking for the problem. Follow the event, look for listeners that are calling into a service layer of some sort - follow the service layer into a gateway or DAO object - throw in another framework, coldSpring, and you can get pretty confused pretty fast. Thats a different story.

I traced down into the machii event and found the listener calls and the view files that appeared to be responsible for outputting this slowly developing content. The view files did not have much content in it - just a mysterious call to an XML function. My investigation then took me in another direction, until i found where the content was getting gathered, not displayed. The output is stored in a group of Objects and then xmlized by another function. Hmmmmm, is there a really compelling reason why this content was not simply being returned as a query object? Light, easy... But not object pure. I think this may be a case of the developer being a bit of a OOP purist and treating CF like Java. And why are we xmling the result? What is the gain here? More overhead and complexity. Perhaps its a case of "we may need this later in this portable format"...rather than YAGNI or KISS. Anyway, this feels like alot of overcooking to me. It took me way too long to find this class that was extending a base view event class - to just find about 15 lines of code responsible for actually outputting content.

Bottom line - private functions in cfcs should not be outputting anything. Let the cfcs do their job of getting data and making decisions about what to do - leave the view files to outputting the results.

OOP is good, in the right places, but not always in every situation.

OO birds eye view

2009-04-02T13:01:00.000-07:00

OO - think in terms of objects

OO - think in terms of data and functions together in a single entity

OO - think in terms of reference, not value

OO - think in terms of encapsulation (self sufficiency)

OO - think in terms of

OO - think in terms of singleton -vs- transient

OO - think in terms of state of an object

OO - think in terms of security (accessors and modifyers) - getters / setters

Software Architecture (MVC)

think in terms of layers

think in terms of separation of concerns

think in terms of maintenance

think in terms of clarity

think in terms of sessions

Desing Patterns

think in terms of DAOs, Gateways, Beans

think in terms of anti pattern (3- 1) - not every entity needs its own service, gateway and DAO

a service should serve more than just a single DAO and Gateway.

think in terms of doctor - patient (a doctor has many patients)

think of singletons -vs- transients

singletons application wide, transients user wide

transients (have state)
singletons (no state)

*for the singletons (many users using a single instance) think in terms of varing
every variable in it. these are objects stored in application scope.

Frameworks

think in terms of maintenance

thinks of tradeoffs

think of consequences

think of payoff (work up front, payoff later)

think of overhead

think of consistency - predicatability

OO programming from domain to presentation layer

2009-04-02T12:16:00.000-07:00

I am always trying to get a better handle on OO programming techniques. I come from that produral background and i think it is always influencing the way i see layer and communication.

If i can think of the objects as two types
singletons - only one copy exists per session per user - these have no state
(these are DOA's, Gateways, Services)

transient - have state and need to keep the state while living in memory
(these are beans or value objects)

In my main application that i support, this means

transient objects or beans that have state (specific data associated with them) are
assessments
standards (performance indicators)
resources

Each of these beans is updated when a new one is selected.

For each user a set of each is created (assesment, resourse, standard) value bean. They are created in the service that is used to communicate with them.

There is only a single service object (a singleton) that is created once when the application starts. The singleton is placed in a application scope and is then accessible to every user who comes to the site. They all share the same instance of the object or class. There is no race concerns because the application (coldFusion) takes care of the threading.

So - one instance of the services for all the users who come to the site. A collection of objects for each user when they initially hit a part of the site that uses the service for those objects.

Also in the service, besides the instantiating of the transient objects, are the rules for when to call the other singletons. The service is the big DOG. It knows about the other services and the other singleton and transient objects. If you looked into the init() of the service.

Again - think like this

- whenever you have data to persist for a value object
- ensure a copy of it exists in memory
- use the DAO to get the updated data (if reading from table)
- use the Form or URL parameters if updating to a table)
- update the current bean in memory
- pass a reference to the bean from the service into the DAO/Gateway when necessary
- pass a reference back to the presentation layer when feasible.

I dont think rules like this are always adviseable, some times it just makes sense to pass by value and not reference. But, in the spirit of OO - think like this by default and work from that position.

I did this in a couple view pages i was recently working on. The the user clicked on a resource or assessment or standard, if the request was to view something - then i would go to the service who who use the id and existing reference to the value object, and pass them both into the DAO gto get the details from the DB. If the request was a update, then i would use the updated values in the form fields and pass them along into the service and update the current bean using the arguments passed in and then pass back a reference to the value (bean) object. now in my presentation layer im referencing the bean that is in memory. Im not actually going back into the db (which is a no no from a MVC perspective) - but referencing the value bean via the object passed along. Encapsulationa and OO techniques!

Im not sure if this is really the smartest way to go about this, but it is my attemp to continue to push out OO concepts and challenge myself to learn to think in terms of Objects and encapsulation.

cheers
What i started to do recently, in the spirit of OO, is to return the pointer or reference to the presentation layer.

3rd party editors - usability

2009-02-03T11:45:00.001-08:00

Ive build a utlility application that uses a 3rd party editor called Fckeditor. Its a popular editor, that is implemented in each of the major platforms, java, coldfusion, asp, etc..

I brought it into play originally for another utlitity application that i was working on. Each of the two utilities are about feeding data to a relational db.

Each of the two utilities needs to upload files as part of their jobs. Lots of text, with images needed as well as other upload types. the challenge is that each utility needs to store the uploads in different places. I could, i suppose use different implementations, meaning give each utility its own set of core files (thats about 400 total) - seems a little overkill. What im looking to do is dynamically inform the path where the editor will upload the images to.

Ive dug into the editor a bit and found the upload configuration file that is defining the path where the uploads are going. Now i need to figure out the smartest way to inform the editor where it being used from and pass that variable into the configuration file to dynamically set the userpath.

If this gets too hairy, i can always use plan A, each utility having its own implementation of the fckeditor core files.....but i really dont want to do that.

stay tuned

Im back - im thinking i may try to scale down the size of the fckeditor core files - since alot of them are for implementations that i am not using. Then each Utility could have its own version of the core files. Then, each would have its own

fckeditor.editor.filemanager.upload.cfm.config.cfm

and i could set one where it is now and the other where it needs to be, including the dynamic updating still needed.
Resources path = userfiles/image
assessments path = assessment/assessmentID/

perhaps...i need to continue my heavy lifting around this before moving into a implementation.

Im thinking about creating a utility helper CFC where i could set a session variable or application and use that to inform the assessments *dynamic portion. In the assessments app, im using a framework where i could use a build in plug in point to instantiate the helper object upon application startup. "bootstrapping".

Application.cfc and Frameworks

2009-02-02T11:57:00.003-08:00

im working on a utility and am setting up a little session state management. I have a request from a customer like this "when we choose a question type of A, can it remember that for the next one record i add?". Of course, a common request, what i would referr to as state management. Keep the last answer provided by the user via the interface and use it to inform the state of the interface. Session variables come immediatly to mind.

I set off to implement this solution. I thought about it for a little while first, heavylifting, my biggest question was where to lookup and update the session variable. I did not want to do it on the view page, but rather somewhere in a *session object. My thinking brought me into the Application.cfc, which is a special *framework like component that Coldfusion provides that have built in plugin points. This means there are points in a request where the developer can interceed and do some kind of processing, testing etc. These built in functions include application start and end, session start and end, request state and end. This is pretty handy IF you ARE NOT ALLREADY using a framework.

I am using machii and so have a means already to interceed where i need to. Additionaly, the framework allows me to interceed in the event that i want, not all the events. That feels a little better than sticking the test in a OnRequest function. I could put logic in the OnRequest and have it only perform when needed - but even then, that wrapper logic would be read on EVERY request. My framework allows me to place the same test in a listener or service request that is ONLY read when i explicitly call for it.

The framework adds overhead, but pays for itself in many ways, including this one.

Bottom line - dont expect to use Application.cfc or the old school Application.cfm IF you are using a framework. This is a quote from mega smart Sean Corfield.

"It doesn't really. Frameworks generally provide their own plugin points and ignore Application.cfm - and they pretty much ignore Application.cfc as well. Perhaps future versions of the frameworks will support / integrate with Application.cfc? "

Application.cfc and Frameworks

2009-02-02T11:57:00.001-08:00

Beans, DAOs, Services, applications

2009-01-20T12:29:00.001-08:00

Im working on a Utility that does standard CRUD stuff. My brain got a little confused, again, in the area of relationships between services, beans and DAOs. Specifically, i could not decide the best way to implement the relationships between the three. In a SOA, we use the Service object as the laison between the application and the domain objects. Does the service also keep the responsibility of creating a persistence bean for a certain object? I think so, i added the instantiation of the resource persistence bean into the init() of the service. Now the service init() function instantiates DOA, Gateway and bean objects. I am using the variables scope in front of each and have tested the threading, which should not be a problem, since each user who instantiates their own service object gets there own copy of each of the other objects.

In my service, I have a set bean method, that updates the "empty" bean object, by passing a objectID into the set bean method - which then goes to the DAO, since thats the object that should have the SQL or whatever DB code you are using. The bean itself should not know about the database that is being used to get its data so it can do its job of persisting. So, the service calls a getRecord method in the DAO, the DAO sends back a 1 record query to the service. Teh service checks to be sure it has a valid result and then passes the query result to the set bean method in the bean itself.

This seems to make sense - following these good OO practices.

Service creates objects needed to do the work requested by application
Service asks the DAO to get a single record, passing in objectID
DAO returns a single record
Service ensure the record returned is valid (this could be done in DAO too)
Service then calls the set bean method in the bean itself, passing in the record to update

In conclusion:

The DOA does not know about the beans
The beans do not know about the database
The service knows about beans and DAOs and Gateways and other services.

new development

2009-01-13T08:54:00.000-08:00

Im about to begin development on a medium sized project and wanted to document some of the things i know i should be thinking about before i begin.

Who is my customer - define this, have them in your mind. You should be able to say in a couple works who they are.

What do they want - get a requirements document nailed down. Thats happening now, my customer is detailing the requirements from our meeting, he will share those back with me for agreement before giving to his client. Be very specific about what the specs indicate will be done in the initial iteration. We could use a front to back design methodology that gets the product in front of the client sooner than later. We may still try to do this. I am following the Agile approach, not the water fall. In other words, create smaller more focused iterations of the product, rather than larger more consuming ones. This is a tenent of good design or process.

Getting down to business. I will follow a mature design pattern, MVC. This pattern will focus on the separation of functionality into three distinct pieces. Think usability in the view layer. Ensure the interface is easy to use, clean and reliable. Not too much clutter or needing to dig to see things. Provide immediate feedback in the interface. Perhaps use AJAX type functionality. This will be a data intensive application, so AJAX techniques would be valuable. At the same time, be sure the application works in both IE and FF. AJAX stuff sometimes is cross browser problematic. I could use the built in CF8 AJAX libraries, but this would require that the hosting server would also be using CF8, which is not quite true, yet. I should stay away from cf8 specific functionality for now.

The controller. I will probably use machii or some MVC framework. Other utilities and the main application all use machii. I *could be consistent or i could use as opportunity to try a different framework, like model glue or Tarten. I could forgo a framework all together, but i like what the framework provides and I know that this application is going to grow in complexity.

The model. This is the part that is most interesting to me. I do like the other layers, but the domain modeling and service, DAO, bean objects are of most interest. I have implemented these patterns a few times now and each new opportunity provides more insight and hopefully a tighter design. I could even try to use a ORM tool to stub out the intial domain objects. The domain design includes how to manage the relationships between the collaborating entities. I will probably use ColdSpring again, since i just think its a superb piece of engineering. Maybe i wont use CS, and show how the objects themselves could keep that knowledge, via init and constructors.

Ill return in a couple weeks when im done with the initial build of this Utility.

Reflection - training new developers

2009-01-07T10:01:00.000-08:00

I have been helping a co-worker do some work that has really caused me to look at some high level principles. I like this, and wanted to capture some of the thoughts. first off, we are following the SOA design patterns in our development. this to me means - creating a service oriented architecture, where the service objects are the big dogs in the playground. they are at the conceptual front of the domain line. They are who is called when some application wants to get at some data.

In our application, we are using machii, so there are listeners that are registered as part of the application. Whenever the application does something - it is funneled through the controller (a xml file) in the form of an event. If the event needs to speak to the data layer - then is uses one of the registered listeners to do that.

The listener has lots of functions in it and has *knowledge of the event and the arguments or parameters *URL variables that are passed around (this is usually either URL or form data served up by a view page. The listeners job is primarily to pass things along - pieces of data that the service will need that determines what to do with it.

This is know as the bus. logic and should live downsteam from the application and listeners. The bus. logic should live in the service and in the persistance objects.

So, while helping my co-worked to understand all this abstraction of layers - i found myself using works like design patterns, service oriented architecture and persistence beans - including anemic -vs- rich beans. When you have to explain to someone why things are how they are, it makes you think very critically about the why portion - and you better have more than a "because thats how i found it" response.

I am also using coldSpring - so i talked about where the service gets its knowledge of things from. rather than the service objects creating its dependent objects itself - that knowledge is abstracted from the collaborating objects and into a *container xml file that does it for you. Brilliant!. I do like coldspring alot! I talked with her about where this new piece of bus. logic should go and where it should come from and why. It was a neat experience.

Im not saying that i have all the answers or that the answers that i have are perfect, im just saying it felt good to explain this stuff and to see her seem to get it.

Be a good investigator

2008-12-04T12:02:00.000-08:00

We use a machII framework around our application. We also use coldSpring to manage the relationships and instantiation of collaborating components in our domain.

A quick review, for my own brain too. Machii helps to organize large scale enterprise level applications and promotes OO design of the application, or at least promotes MVC design pattern. There is no denying that, Machii forces the separation of concerns between the presentation, control and (model)domain layers of the application. It also promotes OO design by using listeners, that do the requesting of data from the domain. It is possible to use Machii and listeners and still be using prodedural programming techniques, guity. Moving on.

The application in question consumes lots of complex data that is served up by the domain via services. This is in line with SOA type architecture. Services oriented architecture. The domain makes available services that the machii application listeners know about. The listeners have knowledge of services and can speak to them. The application does NOT KNOW ANYTHING about the domain or model layer that is providing or peristing the data that it needs.

Picture machii doing its job, housing the views and the events and the listeners, that know about services that speak to the data model layer. Whenever something happens in the application, an event is fired, the event has *commands that are part of it - like requests for data and calls to other listener funtions. The arguments or data provided during the event is passed along via the event to the listener who hands that off to a service. The service knows then what to do with it. Recall that the service HAS knowledge of who it is serving. The SOA architecture promotes the notion of the service as the SOCIAL beast in the equation. The service will have much of the bus. rules or logic contained within it. It does a lot of the heavy lifting or thinking for the other components in the domain. The service knows what do do in this situation or that situation, when this piece of data is missing or if a specific type of data is encountered.
Recall that a service probably has its own set of dependent components that must exist for it to do its job. A common occurance is a DAO or Gateway or persistence bean that the service relies on to do its job. If any of these other collaborating components does not exist, the service fails.
The SERVICES, being social, often need to know about other services, not about the other services collaborating entities, just the service itself. This need to know about each other had much to do with the birthing of ColdSpring. With, as the name implies, follows the concept of Spring in the Java world, which is a framwork that helps manage the complex relationships that exist between the collaborating entities in the domain.

ColdSpring "lifts" the knowledge of the collaborating entities out of the entities themselves and places them into a separate container. This is abstraction at its finest.

Tradoffs - there is always tradoffs when you use a framework, like machii or coldSpring. In the case of coldSpring, that is a slight performance overhead and the need to maintain a separate XML style document. A little complexity at first. The gain is a one stop place to create and manage the relationships that exist between your services, DOAs, Gateways.

We have two separate coldSpring xml files, one that is used by the application and another than is used by a sub- application. When i built the sub app, i originally had the domain components instantiating their own collaborating components, this is the natural way to build the app, not seeing the need for a framework initially, who needs it! Eventually, as the sub app grew in complexity and collaborating entities, the need became more clear. I created a new *bean building xml file (this is the container that holds all the bean definitions). The coldSpring configuration file consistes of bean definitions complete with references to dependent components. CS calls this dependency injection -this is usually reserved for those social services, who need to have their dependent DAOs and gateways and other services to work properly.

The problem

In my sub - app coldspring file, i named a bean the same as one that already existed in the root coldSpring config. file. Even though i pathed the bean in the sub app to a different component, it seemed to ignore the bean def. Seems if a beanname already exists in the current scope, it will not read the next. It could be a problem with how i am using the scope? -

The symptom

The problem reported as a failure to set an injection statement in # 2

1 - model.questions.QuestionService.cfc
2 - assessments.questions.QuestionService.cfc

The Diagnosis

I tried to path # 2 a little different, since I did not want to change the name of the service (this would require me to update the name in a couple other places), but was not successful.
The config file in the sub app was pathed to # 2 but when it tried to do its injection of a DAO, it was reporting the failure in relation to # 1.

The Test

I changed the name of the component in # 2 and updated that name in the appropriate places, a listener, another reference in the CS config file and a reference in another service that was using this and walla - problem gone, lesson learned.

Recall that when you are doing dependency injection in a bean definition in the CS config file, you need an equivently named funtion in the collaborating (injecting) component, with the letters set in from of it. In other words, if you have a service bean being in jected with a DAO, then the injecting DAO must have a setDAO funtion that allows the setting.

Like this - here is the bean defintion *minus the brackets that the blogger does not like

bean id="AssessmentQuestionService" class="assessments.model.QuestionService"
property name="QuestionDAO"
ref bean="QuestionDAO"
property
bean

Here is the function in the service that is being injected

cffunction name="setQuestionDAO" access="public" returntype="void"
cfargument name="QuestionDAO" type="assessments.model.QuestionDAO" required="Yes"
cfset variables.QuestionDAO = arguments.QuestionDAO
cffunction

This is a little intimedating at first, but trust the technology and the beauty of the design. It becomes more clear as to its power and purpose over time, when you add more things to the application and more relationships between collaborating entities.

Prototyping

2008-11-05T11:55:00.000-08:00

Ive been working on some new functionality the past couple weeks, which is nice, since it has been awhile since our project has seen any new functionality. We used to use a process called FLIP, that Hal helms and Jeff Peters worked up awhile back, but the people, including the customers who were involved in this are gone, so i ended up thinking hard about what parts of that process worked and what parts could be left out. A re-cap of that analysis follows.

What works

Front end development first. That's a fine principle to follow while building new functionality. What is the new stuff supposed to be doing? How should it do it, what should the interface look like, what kind of functionalily should be present. All these things help the customer to see things that they are trying to describe. Put something in front of them and let them see it in context of the system where it will be used. I even heard one of my customers say "now that i can see it in place" the other day, more on that in a moment.

Don't think implementation, at least not the database or model domain. Anther one of our developers at the presentation was asking questions about implementation. This was the initial design and presenation of the design, there should be ZERO talk of implmentation. We are focusing on what they client wants!

Keep it light - do not attach the prototype to any real datam, fake it. Hard code stuff in view pages, do not query or instantiate objects in any way in the prototype. When i could myself starting to think these things, i kicked myself. This payed off immediately, since some of what i was prototyping was not needed, at least at this point.
Get it in front of the client, expect multiple iterations before they say "thats it". Make sure that you get the people who are interested or who should have a say involved early. I need to do that now. One of my customers was not present at the meeting. I need to get his input sooner than later.

I am prototyping the new code in the actual application, which required me to do a bit more work, that if i used the prototype toolkit that we used to use. But its work it.

Elicit feedback. In our previous prototyping cycles, we used a toolkit that allowed users to login and leave comments on each view page. That was moderatetly useful. Some of the customers understood what we were trying to do, but others did not get it and it was alot of work and a hassle. The prototype toolkit would get in the way of what they were trying to do and confuse things. They would leave comments on the wrong pages or the login would fail or something would go wrong.

Now, i am putting the new code in the actual application on my localhost and showing it to the group. My next step will be to put the revised content on our test server and give another presentation. The feedback, which is so important will be handled via email via me asserting things back to them and them clarifying. This is not perfect either, but is the way i am approaching.

I am thinking some implementation. The new functionality is a calendar that is showing release dates of critical information in our application. Naturally, AJAX comes to mind, since i do not want to have to reload the application every time the user clicks a new month or year. We just want to drill down into the data and update the calendar without reloading the application. Im thinking this, but not implementing, since i am not doing any drilling into the domain at this point. My prototype is using some javascript to automatically update the calendar when a select box is changed or a pre / next link is clicked, but no real AJAX yet.

I want to be sure the customer says, "that's it for the initial release of the calendar functionality". Then we can freeze things and i can implement the AJAX and other domain code.

Post mortem on major upgrade of application

2008-10-15T11:38:00.001-07:00

Well, its october and we finally got all that re-factored code through our staging and production environments. It was a pretty big move. There were about 70 files to move around between the domain and presentation layers. About 10 were simply moved to a new location, away from the domain objects. this is a mach-ii application, which explicitly uses listeners. since the listeners are part of the application and not part of the domain, i felt it warrented to move away from the *model folder.

Some of the other components (cfcs) were moved from the model root into a specific folder that represented the object.

I updated coldSpring with new definitions to some of the objects and updated paths to existing objects, to their new locations.

I was also able to remove a couple object instantiations and use the coldSpring provided object reference. this simplifies a bit and removes a little memory overhead but more than that it cleans up and organized the code base better. I already had one new developer who is starting work on this application comment on how she likes the organization better, easier to find things etc.

I also ended up splitting up some presentation code into smaller more singular entities. Reuse in the presentation layer is overrated. I had a single view file that was responding to 4 different types of data, which was cool, but in the end, became too difficult to maintain. that reminded me of the fact that 75% of all programming or time that a developer spends is maintaining existing apps. To that end, creating additional view files for each subject is a tradeoff worth taking. The tradeoff is more code to maintain, but less complex, fewer dependencies. In the domain, i did the same thing. There was one of two functions that were responsible for getting lots of different variations of similar data. Again, this is good programming to think re-use and not have 40 different functions that are all doing similar stuff, but as time goes by, you start to appreciate the ease of maintenance - which is supported by more functions that do less or even a single thing. I can tell you that the trade off is worth it. I always appreciate it when i enter the domain into a gateway query that is very specific and not loaded down with 8 arguments, where 4 are required and 4 are not packed with lots of conditional code in case arguments are passed in....where if you make one small change you worry about effecting the other 10 instances of how this function is called.

Part of this move to staging then production also included the removal of deprecated files that were wither moved to a new location or re-factored.

As i said, i think about 70 new files were moved and about 25 were deprecated.

this move also included many updates to the central controller, where i was removing calls to old functions that had been re-factored or removed and updated paths to listeners, that are registered in the controller and removed references to view files that had been deprecated. view files are also referenced in the controller.

Thats it for now. What a move, really minor problems while moving - biggest issues where keeping the labels, thats how we manage deployment, current and on the tip version of files. I ended up missing a couple files, no label and did not move the tip of the label on a couple others. these problems only took a few minutes to correct. The most grueling part was when our testing general was looking real critically at the layout and recordsets of the views that i had re-factored that were being feed by re-factored queries.

Good experience. Looking forward to the next one, thought it be smaller.

model refactoring project continued

2008-09-02T09:34:00.000-07:00

Im working on a small update to some core logic in one of my frequently visisted objects. A couple of the updates, including to the controller (this is a machii application) are requiring me to bring along some other changes i made a couple months ago and have been sitting waiting for something like this to come along. I could have made a branch in our source control software to deal with only the changes to the current project, but chose not to.

When i looked back at the changes i made a couple months back, i noticed the coldspring integration i had started. I had integrated a few components into the coldspring configuration file and injected them into their dependent service components. All good! I decided to integrate the current component and its dependent components too. I was pleasently surprised when it only took me about 15 minutes to do this work. Ive got my head around coldspring a bit now and new just what i wanted to do and why. The changes are listed below.

1 - identified the collobarating objects and gave them bean definitions in the config file
2 - identified the dependent object and gave it a bean definition.
3 - injected the two colloborating objects (components) into the dependent object
4 - added set methods for the collaborating components in the dependent object that - removed the init method in the service
6 - tweaked the colloborating components to not require a property on init, changed the default to no and provided a default value. If a value is passed, it will take it but does not require.

Each of these components are singletons, which are perfect for the coldspring container. They have no state and simply provided data that is kept in a related bean component. I caught myself trying to add the bean to the coldpring config. file, but stopped when i clued in to the bean is not a singleton, it has state that updates frequently. I ended up with a method in the service to the bean that checks to see is a session scoped var exists, if not, creates one and used it to update the bean during the user session.

Then i moved into part 2 of this operation

As i am looking at the service, i see where i should have put certain methods into the DAO not the Gateway. I think initially, i only had a gateway component, but as the requirements grew, so did the component. Now i have a DAO and am putting requests for a single rec or data item into it, while leaving the gateway as the aggregator or record sets.

Finally, im looking at this wiht object eyes

and seeing what can i move to the bean and keep the persistence stored in the bean.

Effective Developer habits

2008-08-29T07:05:00.000-07:00

These are habits of effective developers. I gleaned a lot of this from the helms and peters podcast. I listened to this a couple years ago and again today. Really good stuff.

1 - Pursue professional growth. Always make time to attend conferences, trainings etc. Use the internet and its plethora of technical podcasts, articles, and blogs. There are so many skilled smart people who have been down the same path that you are on and have documented their experience.

2 - Think Google to help narrow down the search for related resources.

3 - Blog yourself. For me, its help A LOT to internalize things by writing them. Thats why this blog exist.

4 - Think user first. Do not let your vision take precedence over the user or client vision. Try to engage them as much as possible when gathering requirements.

5 - Prototype. If its a new product or functionality build the front end first. There is a lot of smart people who advocate for this "front to back development approach". Build the prototype, involve the client actively. We used to follow a process called FLIP, that emphasized the prototype first while iterating frequently with the customer until they say "thats it". There is no thought given to the implementation, language, DB or framework during the prototype. This process takes at least half of the entire product development life cycle.

6 - As a developer, do not assume superiority. Be amiable, supportive, encouraging. Believe that everyone who you come in contact with has something to offer.

7 - Think first, code second. Try to see the entire problem or big picture. Seek the birds eye view before starting coding or database development.

8 - Document. Not document your code, but code your documentation. Think hard about what is good documentation. Consider that someone else will be maintaining this code.

Object oriented design

2008-08-28T08:52:00.000-07:00

Today, I was listing to Hal Helms and Jeff Peters discuss object oriented design. They were talking about inheritance -vs- composition. The main point was how composition has a is favored over inheritance, is a. Ive been hearing this for awhile, but have not always understood, probably because its a little abstract, since im not doing much in the way of new object design or at least not with extending base classes.

One concept was that base classes are really not ever instantiated, but extended. This notion was further described this way:

A goal of class programming, remember this is the model layer, not the view of controller, is to create stable reusable objects where commonality is captured in a base class that can be inherited or extended by a more specific class. Another way to describe this base class is as a super class.

The goal is to allow base classed to be easily extended (composition) to incorporate new behavior without modifying existing code. This creates designs that are resilient to change and flexible enough to take on new functionality to meet changing requirements.

Design principle:
Classes should be open to extension and closed to modification.

These concepts where discussed around the context of the Decorator Pattern.

Remember, when you abstract the differences by composition, you are adding complexity to the application. Dont forget to think in terms of trade offs. Nothing is free, when you build more extensible code, classes, by following this excellent principle, you are adding more complexity to your logic. Only apply the "open closed" principle where needed.

ColdFusion Frameworks, coldbox, tarten, MG, fusebox, machii

2008-08-27T11:11:00.000-07:00

Today, i came across a number of helpful/interesting podcasts, articles. First, the helms and peters podcast on Framework Shrink is both entertaining and informative. During this cast, fusebox, MG and machii are all praised, frameworks in general are praised and people who program willy nilly are not praised. They joke about the NMM (no methodology methodology) this is characterized by the developer who thinks they are too smart to have to use someone else ideas, why use a framework when i can solve the problem myself. This brings to mind the debate between Hal Helms and Simon Horwith. This was not so much a debate as a informative discussion about the pros and cons of frameworks. With a decided edge going to the wisdom of using solid solutions created by others that follow best practices and encourage solid design for large applications that are scalable, maintainable, predictable (thats what the use of frameworks provide).

I followed a thread to coldbox, another CF framework that lead to this discussion about the value of frameworks. Who is using coldbox.

There was a mention of Tarten, which i had not hear of before. Interesting, in my brief read, Tarten encourages a service oriented architecture, where the controller speaks only to a service that acts as a mediator to the bus. logic in the model.

This is the common thread through all of the frameworks that i have been into and out of the past few months. Each promotes the

tiered architecture
MVC design pattern to achieve separation of views and bus. logic via a controller
OO design
tight encapsulation
loose coupling
reuse of small singular type classes or objects or with CF, components
the use of a controller to coordinate/direct requests made by application
pushing of bus. logic into the model layer
use of XML style controller
preference for application to speak to the model via a service (tarten).

I also found this useful cf portal site.

I really liked this part of the conversation, quoting Luis Majano.

"Most major design patterns do apply to Coldfusion and decoupling and object oriented approaches are posible. Yes, they will make your application more complex, harder to grasp, and event WEIRD!! But that is the intent, to take your application to an Enterprise level. You can continue to build procedural code for certain applications, it doesn’t mean its bad. But for high availablity and enterprise applications, I would go with a framework. The flexibiliy and architectural extensibility that it will give you, cannot be found in other approaches. It will be hard to grasp and you might think, why do all this work, all these calls. Object Oriented architecture is not easy and you also have to note, that some complexity on these approaches, will make you sacrifice speed. But the benefits will be tremendous."

Frameworks, MG, Machii or Custom

2008-08-20T13:01:00.000-07:00

I've been messing with MG the past couple days. I have a small application im working on, and decided to give MG a go. Things were going fine, it was taking me longer to solve the problem because i was learning the framework. This is ok, acceptable when learning a new framework. I spent a bit of time listening to podcasts, reading blogs and looking in the official Model-Glue documentation center. Once i turned the corner on getting the MG controller to set the args properly from the event - i was on my way. From this point, MG facilitating communication between my gui and model just fine.

It was about this time that i started to feel like it was a bit overkill, the framework is pretty light, lighter than machii, but i still was not feeling good about the use of it in this case. I just was not doing that much and felt like the overhead and increased complexity was not worth the cost. Like a big brick, the vision of a streamlined *custom framework hit me in the head. I could hear Simon Horwith whispering in my ear. So, i decided to scale back a bit. I used the index.cfm file to handle the bootstrapping and the rest of the setup work. It reminded me of the fusebox settings file, where application level variables and pointers are set up.

Index.cfm is now responsible for creating the object pointer into the service and also listens for actions (*events) such as insert, update or get. Thats about all this GUI is doing. Depending on which action is executed (listened for) i am calling the appropriate service method and passing along form or URL vars appropriately.

These are the following design principles adhered to:

*MVC design pattern
*separation of concerns (view just reacts to what is provided via the controller (index)
*encapsulation of bus. logic (all in CFCs)
*asynchronous calls, where helpful to user
*no SQL in the views (see above)
*safer from spammers and hackers, SQL is down stream protected by the service layer.
*no extra overhead (MG or Machii or Fusebox)
*intuitive - less complex

tradoffs

not as scalable as MG, Machii or fusebox

If the requirements dictate, and a more scalable framework becomes necessary, i can simply trade in the index.cfm with its event and listening responsibilities for a MG or MachII framework, where we can use an XML style central controller with specific listeners or messages. Since i put the bus. logic in the services and the database interactions in the DAO, Gateway - its a can of corn.

Model Glue

2008-08-14T13:21:00.000-07:00

I ran across a ModelGlue folder on our test server today. I have been hearing about MG for a couple years. An easy to use CF framework that promotes MVC. I decided to take a look. I found a read me file in a predictable location and opened it. It had excellent instructions about how to copy a certain folder into your web root, open a controller and change a couple properties in the xml config. file. I did all this, made a silly mistake and corrected it and had the sample RD site up and running in 20 minutes. Impressive. Not me, it.

I recall the setup and initial forays into fusebox and machii and neither was anywhere near as easy as this. Granted, it looks a lot like machii with the xml controller, events and such, but still, 20 minutes from start to end. I must say, i am impressed by how easy that was. I will have to give this a ride in the future.

I sent Joe Rinehart a note saying as much.

ModelGlue, coming to a theater near you.

AJAX - javascript little opps

2008-08-14T09:58:00.000-07:00

I have been using a little AJAX technique in a couple places and was having two separate problems that i worked out.

First issue: i have 2 separate html divs that were being reloaded on the same page. The problem i was having is the second call that was informing the second div on the page was sacking the first. In other words, I had come like this calling two different jscript methods

function loadQuestionsStandards(assessmentID,category,type,level){
showStandards(category,type,level);
showQuestions(assessmentID);
}

Each function showStandards() and showQuestions() contains code like this

var url="views/filterQuestions.cfm?&assessmentID=" + AID + "&showAllQuestions=" + flag ;
oXmlHttp=GetHttpObject(updateQuestionList);
oXmlHttp.open("GET", url , true);

where updateQuestionList is the name of a layer in the page called by the url var.

The results of the second call to showQuestions was polulating both divs on the page. Finally, i changed the true property to false in the first method call and it worked.

In other words, the reload of the page only occured once, not twice and it correctly reloaded both layers. I did not find any help around this problem in the blogshere.

The second problem only showed itself in our production environment. Hmmmm, did not occur in our test or staging environments. That remains a puzzle to me. The problem was in the same line of code as the first problem.

oXmlHttp.open("GET", url , true);

When i was trying to solve the first problem, i changed the GET to POST for one of the functions and forgot to change it back. Probably forgot because it did not make a difference until it made it way to production, where it failed gracefully. I got a message back from the Jscript API, i presume, that said Length Required.

I was able to trace the problem back to a specific function where i had made this GET to POST change.

Moral of the story? not sure, but both of these issued had to do with the

oXmlHttp object.

CF Conversation

2008-08-13T13:08:00.000-07:00

I listened to this podcast today. This interview highlighted a couple things that i have been into and out of in other blogs, podcasts about the CF community, perception of CF as a light weigh tool, frameworks etc.

CF has come along way, especially with the last couple of releases that make CF much more object like. I can see how CF has grown up over 10 years, from its initial release which really was alot like HTML with its tag based format. It was easy to use and easy to create dynamic content. CF excels at hiding much of the complexity of what it does in the tags. This results in users being able to *just do their work. In the past couple years, i have been working more in the architectural side of things than in the front, so i appreciate the emphasis on CFCs and OO techniques.

There is a perception that many of the CF developers, because of it ease of use, do not have the traditional CS type background and consequently are sloppy programmers who rely too much on frameworks. An interesting point. CF's own efficiency has spawned lots of programmers who otherwise may have never been programmers. Folks who only dealt with static content, layout and design had access to programmatic tools that were once exclusive territory of programmers.

There is the perception among programmers that the within the CF community, there is not enough emphasis or development integrating CF with other more mature back end solutions, like Java or PHP, for example. Andrew Powell is a guy who has been working to bridge that gap. This is a good ADOBE sponsored article around this type of integration. If CF is to continue its acceptance into the *big players sphere, it must play better with other technologies. Matt Woodward posts a helpful article around Java integration.

The discussion also talks about the proliferation of CF frameworks and despite the backing of the CF *elite, are overused and are a crutch to many CF programmers. Is there a perception in the CF community that if you are not using a framework, you should be? Hal Helms and Simon Horwith have this debate about frameworks.

The frameworks include, machii, coldBox, model glue, fusebox, coldSpring. Each of these were mentioned. There was a good discussion of trade offs and what that means.

For me, i started CFing without using any frameworks. In a perfect world, CFers would have a change to program without any *overhead of a framework. This aids in the understanding of variables, scopes, and other application wide settings and how the whole bootstrapping process occurs. The frameworks hide many of these concepts and could create a programmer who does not really get some of the crucial concepts behind the code. This could result in programmers who cannot program outside a given framework. I think the frameworks are very useful in some applications and perhaps a bit overkill in others. The size of the app is a big factor. I like the idea of a framework because it creates predictability in the application. This is important for the future of the application and as new people come into it to support it.

There was also some good discussion around the software life cycle. A good reminder that we should do our heavy lifting before we start programming and that we should not start the development in the database. FLIP was mentioned, since there was discussion of frameworks. I think i heard these numbers:

50% time gathering requirements and prototyping
30% implementing the prototype
20% testing and documenting

Was a mention that Flex has really become a popular prototyping tool.

ColdFusion Growing Up

2008-08-13T08:00:00.000-07:00

I listened to a podcast today about something i have been reading in blogs a bit the past couple months. Old news to some, but new to me and important to understand the larger picture.

Once upon a time, ColdFusion was just a little player on the larger scene. the Allaire brothers created the initial taging language way back in 98,99? It is telling now that ColdFusion has 3 different rendering engines and a couple open source projects and is in discussion with educational groups for free liscensing and curriculum, to start offering as college curriculum.

There are 3 different organizations that are offering a ColdFusion rendering engine.

Adobe - with Coldfusion
Blue Dragon - new Atlanta
Railo

I was listening to this podcast today where they discussed Railo in detail and the need to have a standard CF rendering engine, since there are now multiple players. the idea of a CF core that was implemented by each engine with plugins or addons or lib functions or something like this to allow diff. additions by diff. engines.

Its all good - the maturation of a platform like ColdFusion.

Refactoring Bus. Logic

2008-08-13T06:37:00.000-07:00

The past couple weeks have had me back into old problems. I had been in each of these holes before, but was back with new requirements. As i looked at both of the functions in the CFCs, i found myself struggling to add the new requirements because the way the functions were defined was not intuitive. In one case, i ended up refactoring the way the logic was working. I should say i separated the logic into two different queries and then used a union to join the result set if needed.

It took me a couple days of going into and out of this function before i was able to see the solution that i ended up using. I was talking to another developer about this and concluded that we need to see things in our own model to understand them before we can enhance something. I was temped at one time to create a new function and simply leave this one that way it was, but i fought that urge and eventually saw a cleaner way to solve the same problem. Be a technician, bot a demolition man. I added a comment in the function to the effect that i hoped the next time someone traveled down this path into this function, that the bus. logic would be clear to them.

Good code to me means clear code, not necessarily fewer lines or clever, but clear to the next person who may be coming into the code to try to enhance it.

The greatest threat to maintainable software? Complexity! Someone said that once.

Moral to the story. Be patience and if code smells, give yourself ample opportunity to re-factor the code in a way that does not smell, is easier to understand and enhance for the next Joe who comes along after you.

Blogs and Podcasts

2008-08-13T05:40:00.000-07:00

As a developer, there are many ways to approach solving the problems that you encounter. One of the primary points i am making is where do we find inspiration and ideas for how to solve things. I have been making alot of rounds lately in the blog sphere. I cannot stress enough how much outstanding fodder is available in peoples blogs. Someone, Brian Hegeman, once encouraged me to use the blog sphere to find answers to questions but more than that to stretch my understanding of the bigger picture. I was not ready at that time, probably because i was too busy just trying to understand the code base i was working on, supporting ect. I was fortune enough to work with a couple guys who were very talented programmers/architects. There was much for me to learn.

I made a decision after the cf-objective conference this year to spend more time stretching my brain with other peoples perspectives and ideas. Over the past 3 months I have been almost daily going to blogs not looking for a specific answer to a problem, but just to listen in on some conversations. I also joined a couple specific groups, where the conversation is specific about a framework, machII and a model layer manager called ColdSpring. These are specific frameworks that the main application i support uses. As part of this blogging experience, i have created a public space trying to share the learning and organize some of the blogs i have visited.

I have found myself also listening to a few podcasts. Some people may prefer to read, but the podcasts are very useful and pretty focused on relevant topics for the ColdFusion developer. I have found that a couple different CF related podcasts have been around for a few years. Hal helms and Jeff Peters have been doing one for awhile as have Bryan Kaiser and Michael Kaynie. This format starts out discussing relevant CF related news, then typically has someone interviewed. In 2006 Matt WoodWard and Peter Ferrel of machii and CF fame started a podcast called ColdFusion Weekly.. The ColdFusion weekly has recently stopped creating new podcasts but a couple others have just began. CF conversations is more of a round-table interview format.

Here is a short list of topics that i have been plugging into the past couple weeks in various blogs and podcasts.

SQL injection and protection
Marketing CF
Creating more CF developers by giving CF away to educational institutions (ADOBE)
Creating an official curriculum for Universities to adopt
CFAJAX, built in ajax tags for CF8
Krugle.com - code search engine
FLEX -vs- AJAX debate
Framework or no-framework debate
Flex as the view layer, CF as the model layer, machii or model glue as controller

If you wanna be a developer, then pull your head out of the hole and embrace the blog sphere that has so much to offer.

AJAX mussings

2008-07-29T13:15:00.003-07:00

Today, I spent the better part of the day following a path i had previously blazed, AJAXing. I was looking at a specific request that my user made regarding a form that needed a little new functionality. I knew i had used AJAX techniques previously. This is a form with a lot of filtering option and a lot of data, idea for AJAX or asynchronous communication. This form needs to be able to make requests and have the data update without having to load the entire form or page again. I am also maintaining a lot of state in the page, so keeping previous selection is important.

It took me awhile to get my head back around how the AJAX was working, which told me i had not really internalized it that well, so here goes a little blogging on how it works, at least how i am using it.

I have a container.cfm page that has html controls in it. The controls i am using are select lists and radio buttons. I have javascript method calls i am making on the clicking of these controls, also on the loading of the page, to handle initial state. The controls call the jscript method and pass a parameter or two. The jscript method used some fancy schmancy script reload a portion of the page, which includes a call to the server (db) via a oXmlHttp request. That code looks like this

function showQuestionsForItemMapping(AID, flag){
//alert('in ' + AID + flag);
var url="views/filterQuestions.cfm?&assessmentID=" + AID + "&onlyNotMapped=" + flag ;
//alert(url);
oXmlHttp=GetHttpObject(stateChangedQuestions);
oXmlHttp.open("GET", url , true);
oXmlHttp.send(null);
}
function stateChangedQuestions(){
if (oXmlHttp.readyState==4 || oXmlHttp.readyState=="complete"){
document.getElementById("questionsToMap").innerHTML=oXmlHttp.responseText;
}

In the example, the jscript method showQuestionsForItemMapping() is called from a container.cfm page that has a

named questionsToMap, which is where the results of the page processing display. Notice the file views/filterQuestions.cfm is called and processes with new parameters passed in from the container file. The URL, which is set to the filerQuestion.cfm page is reloaded via the cool oXmlHttp.open line and then the stateChangedQuestions() method is called and the questionsToMap div is repopulated. Sweet stuff - a little more complex than if you are reloading the entire page with an http request or reloading the entire event in a machii framework, but worth the responsiveness improvement.

There is lots of sample AJAX like code avail, but the key thing to get is that you can access the back end of your application and get refreshed query data without reloading the entire page. This results in a significant improvement in the responsiveness of the form.

I had to draw a picture on a piece of paper earlier this am when i was struggling to get my head back around this. I ended up drawing something like a container with a couple div tags included in each. With arrows indicating that the div tag include stuff was populated with the container and its link off to an external jscript file.

This also helped me to understand better the nature of asynchronous call -vs- a synchronous call. Flex too uses the asynchronous model with ActionScript rather than javascript to communicate with the server.

Refactoring MVC

2008-07-28T13:27:00.000-07:00

I am continuing work refactoring a fairly large amount of code. Initially, i added ColdSpring to manage the model objects relationships, dependencies etc. As i moved toward completion of this work, i started looking more closely at a couple of the DAOs and Gateways that i had rewired. I noticed a bit of code left over from the initial incarnations of these components. These components have been around a long time and are used in the *main application differently than in this *sub application. I thought it a good idea to create a components and store them within the model path of the sub application, rather than in a more generic /org. path. I copied the components from the /org. path, rewired their init() methods, actually removed them since ColdSpring is now managing them, and removed a good deal of the existing functions that were needed in the main app but not the sub app, and added a couple new methods that were previously in a cfm that i was including. I could have continued to add more methods to the existing old bloated cfcs in the /org path, but decided for a clean break. As i was refactoring today, it felt like the right decision.

I have a couple view pages that are using AJAX techniques, so the event context or que is not reloading - so i had the lookup code in a cfm file. I moved that code into the respective Gateways (one for item mapping, the other for assessment questions). I added methods to their respective services and called the services from the view page, using the object pointer provided by the ColdSpring framework.

I need to figure out how to direct the AJAX calls via the machii framework - so i could use the listeners to get the updated request sets. I don't think this is possible, since we are not and do not want to reload the entire event framework on each of the requests - thats the gain provided by AJAX. So, i use the ColdSpring provided pointer and call the service directly from the view page without reloading the event que. This is still not perfect, but moves the SQL back into the gateway where it belongs and allows me to reuse that code if i swap out the current view with another, say a swf.

I stumbled across a blog today...

2008-07-23T13:10:00.000-07:00

Written by a former co-worker. Turns out he wrote the blog application using machii. As i dug down into the application, i was pleased to see so many best practices in play. Just a few:

the application uses filers and plugins wisely, uses event-args in view pages, this creates a single point of edit - so we always know where to find variables defined in view pages in the event that is including the event.

view, controller(s) tightly coupled, along with the plugin and filter CFCs - they are part of the application.

A sub application to handle administration duties.

The model layer contains the listeners, which i prefer to store in a separate physical folder - since they are part of the application, not part of the model. The *entities modeled in the application are organized by entity folder with a bean, manager (i would have used service) DAO and Gateway in each folder. One of the entity folders did not contain a bean, so the developer was not blindly following the 4:1 design pattern, thats a good thing. He could have had combined service or manager responsibility for a couple of the entity managers. They are similar and both are a little light.

The listeners seem to be only passing control along to its respective manager, while the managers are instantiating their dependent DAO and Gateway objects. There is no ColdSpring or other model manager at play. As a consequence, the collaborating components have knowledge of each other sprinkled in to each other. Listeners are instantiating managers, managers instantiating DAOs, Gateways and other managers.

Listeners are referencing controller properties to pass along as args to managers. If a model manager was in play, it would be doing this, promoting lesser coupling between the listener and manager (application and model).

Objects treated as objects, passing by reference. The DAO is passed in a reference to its bean and uses it when updating the database.

Filters with configure methods, like listeners, they use configure not init for initialization and reference controller properties, since the filters, plugins and listeners are all registered in the controller - they all can access the properties. One difference is listeners extend listeners, filters extend filters and plugins extend plugins, all different parts of the machii framework. Remember to think of the plugins as cross cutting - or needed across all events in the application. In the plugin configure method, there is a UDF object created that is called in the pre-process of each event to get a tick count - what a geek. Interesting too that the developer stored the UDF.cfc with the views?

Remember each non-correlation table *should have its own bean to represent a record from the table when that record is in play. That bean should contain its own validation logic, avoiding the lean bean syndrome. A gateway to aggregate larger number of records from the table and a manager to handle requests of the bean, DAO or gateway.

In summary, lots of abstraction and encapsulation - promoting reuse and ease of maintenance.

ColdSpring OO design refactoring

2008-07-16T10:41:00.000-07:00

Today, i begin a minor - major rework of a piece of software that i created about a year ago. The primary areas where i intend to do this work is in the model layer of the application. I plan to re-factor code by moving bus. logic further down stream into the bus object bean. I actually need to use that too, i am not really using the bean to do the CRUD work.

I plan to use ColdSpring to create the bus object, the service and its dependencies and to tweak the controller to use the service where necessary. I will tweak the service to utilize the CRUD methods in a more pure OO implementation. This means passing around the reference to the bus object and using it when performing the CRUD operations. The refactoring in the service, DAO and Gateway will include removing init methods, since ColdSpring will be handling the creation, initialization and dependencies. As a result, the knowledge of the collaborating entities will be lifted from the collaborators and placed in an abstract container, ColdSpring. This again promotes reuse of the tighly cohesive objects with little coupling. The coupling is abstracted away.

The results of this refactoring will not be evident on the user side, there will not be any changes to the GUI, probably a bit to the API, but the actual changes to the application front end will come later.

I will check back in with progress later.

Hi level steps:

1 - create a new services configuration file in the sub app for the objects to be created and managed in the assessments subapp.

2 - plug coldspring into the machii controller

3 - point the plugin at the services file

4 - add the objects to the services file

5 - modify the objects added to the services file, removing the knowledge of each other, remove the init methods. Create setter methods in services, so dependency injection references will work! Remember to name the setter method the same as the injecting method, like setBeanName. For objects that have init() methods left, DAOs, Gateways, Utils, if instantiating from CS, pass in required parameters using CS provided tool, $varname. For now, i decided to not require the parameter and gave it a default value, this way, i can simply add the parameter in the CS container at any point and it will just work!

b - other things i needed to clean up in prepping objects for CS and OO purity included; removing extends from two of the objects, these are old from years ago, i copied into my application space and noticed they were extending listeners, opps - i noticed a bunch of extra methods after i had created and dumped the bean, when i looked more closely, i noticed that the objects (assessmentDAO, assessmentGateway) where extending the listners - that was a mistake and highlights the fact that these two objects have sat out in space and not be used. One of the objects was not returning itself either.

6 - I currently have the bootstrapping code in the index.cfm file in the root of the sub-application. I wanted to follow the best practice from CF objective machii training where we would use Application.cfc and load all the bootstrapper code in it, and leave a empty index.cfm file. I tried that and had problems, and was not willing to look further into it.

7 - I also spend time in the listeners, removing object creation code from the configure method. Im still not totally clear what the best practices are for referencing bootstrapper variables created pointing to the coldspring created objects from within the machii listeners. I am currently using variables.amanager = application.CSBeanFactory.getBean("beanName");.

Java Coldfusion Spring Coldspring

2008-07-09T09:36:00.000-07:00

I was reading Brian Kotek blog today and came across posting about CF objective - in his post he mentioned Andy Powell session about using a Java Model and a CF controller and view. I just happened to listen to the podcast on this the other day, it was a CF weekly podcast from 2008 with Andy, Matt and Peter. The valuable grok?

Coldfusion and Java are becoming more and more interchangeable - not competing, eachother, but integrating better. CF is still the faster way to go from a-z and has better integration with stuff like Flex and other tools.

CF has frameworks specific to it, like machii, Coldspring, Transfer.

Java has frameworks too, lots of them, notably, struts, Ruby, Spring.

CF = ColdSpring to manage model
Java = Spring to manage model

Another interesting point from Joe Rinehart regarding coldfusion, java, html and flex.

"As I've been moving away from doing HTML UI's, my perspective on CF has changed a good deal. While I think ColdFusion is top-notch for doing HTML UIs and the whole view/controller side of the equation, modeling applications in CFCs has become both a hassle (typing them kills me now that I'm used to other languages) and a liability (they're _still_ not terribly performant in comparison to raw Java, where I can still go dynamic via Groovy). Because a good deal of my work is now in Flex, I have less and less of a reason to use ColdFusion unless I need to render HTML - at which point it's simply the best tool for the job and definitely worth its price a few times over."

ORM transfer

2008-07-09T07:15:00.000-07:00

I'm reading a post by Brian Kotek today and came across a link to another blog about ORM. I have been hearing about ORMs for a long time, i recall when Tracy Logan, a former co-worked and extremely talented programmer, brought this up a couple years ago. Something about Transfer automatically generating cfcs for you and basic SQL. My initial reaction was defensive "why would i want a program that does my job for me? - thats my job". I suspect that is a typical reaction when one does not really understand something, disparage it since you do not understand it. Anyway, I have heard other coldfusion developers talking about ORMs in the past but it has remained to me an abstract concept.

Today, when i when to this Transfer ORM site, i was ready to listen. The high level statement about developing OO web applications was very succinct.

"When developing an Object Oriented web based application, it is normal to have a database with relational tables and a series of objects that represent that data."

First off, i did not know that Transfer was written for ColdFusion, i learned that ORM means "Object Relational Mappers". It may be that until now, my OO skills where lacking and i was not ready to see this for what it is. It may also be that i am currently not doing much new development, most is refactoring. I will take the same approach i have regarding OO design, machii, coldspring, design patterns - slow and in small bits. I think too that once you have *struggled with CFC plumbing in DAOs and Gateways and experienced enough create, edit, delete, read method writing including the tedious SQL then you are ready to see this type of tool as an asset.

Just the intangible gain of having worked with an ORM is valuable. There is always something to glean when trying new technologies.

Refactoring, OO design, abstraction

2008-07-08T11:15:00.000-07:00

I came across a blog today that informed my understanding a bit...here is the

The author speaks of good OO principles regarding model design. He specifies 4 layers or tiers, with the service tier as the primary that the controller speaks to. He talked about the problem that occurs when one dogmatically applies the 4:1 ratio, a service, bus. object, DAO and gateway for every entity in the model. This is what Sean Corfield also said to me about avoiding the anti - pattern.

Its real hard to see this at first, when you are simply trying to get your head around why you need all these tiers and specialized objects in the first place. Eventually, this stuff begins to sink in and you state to see the beauty of the OO designed model, then you can start to consider that sometimes you don't need a specific service for each bus. entity. In fact, you probably do not and a single service could serve like minded objects. This could also be true around DAO's and Gateways. Use the 4:1 approach as a guideline, not a dogmatic rule.

I read a good Hal Helms article yesterday about the workings of an OO designed model and how its really a bunch of little encapsulated objects collaborating with each other as needed to get the work done. Think of an ant hill and how each ant has its own special little thing it does, when looking at it from ground level, its very intimidating, trying to figure out who is doing what, but lift up a few feet, take a more global view and you can see the entire orchestra of work.

Another good point was the refactoring that occurs as you work through a model over time. He describes his experience this way, I started seeing logic in my controller that belonged in the model, so i would move it into the service layer. Then i would see the logic in the service layer really belonging to the bus. object, so i would move it into there. His definition of refactoring then sounded like pushing logic further downstream, where it belonged creating rich bus. objects that took care of themselves and leaner service entities that took care of calling other objects and directing traffic with a smaller amount of bus. logic. Its totally legit to have bus. logic in the service, since the service is part of the model layer, while listeners in frameworks should not have bus. logic, since they are part of the application, but alot of that logic really should be in the bus. objects.

Then he went on to talk about the abstraction of the service layer into a base or super service object that could handle calls to like methods across similar services. This is applying the principle of if its the same, then pull it out of the two places and put into a single place and use it as a base. This abstract service would then be extended by the concrete services with the ability to override the base method if needed. This is good, but does add a bit more complexity in the base class.

I also listed to a podcast today about CF and Java working together, which reminded me that CF is still not a pure OO language, its like an OO language, this technique of basing and extending is very much a core OO principle.

Finally, the author discussed the use of ORMs like transfer to automate the creation of the bus. objects - relieving the pain of having to do the plumbing of each of those objects. This reminded me of previous readings about programs like reactor that would do a reverse engineering and read the database and create sub. object stubs for tables int he DB., hopefully skipping over association tables. This stubbing likely includes an init method that sets the tables cols to some value and creates getter and setter methods for each.

Problem solving Coldspring

2008-07-07T10:45:00.000-07:00

I had been experiencing a little problem with my ColdSpring code. It took me three attempts to see what the problem was. I had been coldspringing a couple services in our main application, meaning i was removing the object creation code from the services, and placing in the ColdSpring container. The trend chart has a service, DAO and Gateway object. The trend chart also uses questions from assessment exams - the question object has its own service, bean, DAO, and Gateway. The trend chart service has a dependency on all three of these other objects or collaborators, trendDAO, trendGateway and QuestionService.

I first created the 'beans' for the question then for the trend chart. Then i wired up the questionService with a reference to the questionGateway and the trendService with the trendDAO, trendGateway and questionService.

Once the wiring was done, i went about setting up the service objects to allow them to be injected . Starting with the questionService, i added a setQuestionGateway method - thats the object that the questionService is dependent upon and the services file is trying to inject during the questionService creation. Then i added three setter methods to the trendService, setTrendDAO, setTrendGateway and setQuestionService - these three dependent objects are injected when the trendService is created.

Once this was completed, i was getting an annoying init() method error in my trendService object upon creation...hmmmm. I looked at this over a couple days, tried messing with the services file definition and with the depend objects but to no avail. After my vacation, i opened the offending trendService file and almost immediatly saw that my service was extending a the listener class. Opps! - The service does not extend a listner class, its not a listener. Once i removed that, it exposed another small error, which was a pathing problem to one of the dependent cfcs. Now thats its cleared up, its so obvious and reminds me to not be careless with cutting and pasting and typing.

Finally, once the wiring was working, i removed the init() method from both of the service objects, i had commented them out during this phase - since all the initialization is not handled by ColdSpring. Thats the payoff - there is less coupling and knowledge sprinkling between the collaborators.

Moving on to ColdSpring ize more objects....

programming problem solving

2008-06-23T07:57:00.001-07:00

I have been working on my little developers application, with the intention of implementing pure OO techniques and coldSpring. I am also implementing machii framework version1.6. I will start to exploit the new machii features later in this process. For now, its more about proper modeling of classes or components. Keeping things where they belong. I mean keeping the model layer agnostic of the application that is using it, keeping bus logic in the service or model layer. Keeping validation logic in the beans, avoiding anemic bean syndrome.

Initially, i put the object creation code in the service for its dependent dao and gateway objects, got that working, then plugged coldSpring into the machii framework, ensured that was ok by creating the pointer object into the coldSpring bean factory (the CS black box). Once that worked, i added the acual bean creation code to the services.xml file (thats the one cs consumes to read your component definitions. I defined the service, DAO and Gateway components in the services xml file, with the DOA and Gateway as ref. objects within the services object. I then added the setxxx methods to the service object and finally removed the code from the init method in the service.

Once that was working, yea! I ran across a blog where someone mentioned creating a utility debugger and using it to dump from within a cfscript block. I probably read something like this before, but i was not ready to grok it. Now, i groked it. I set up a utility cfc and registered it in the coldSpring container (services.xml) and referenced it from the bootstrapper object, Application.cfc. I created a application scope on it, so i could reference it from any objects in the model. Ive used it a couple times already, and find it very useful. Brilliant!

Think of coldSpring as an attachment to the model layer. At application start, there has to be some instruction that says reference and scope the beans that are defined by the coldSpring framework in the services.xml file. This does create a thin layer of coupling between the application and the model layer, but its contained to a single bootstrapper object that has the knowledge of the coldspring framework.

Think abstraction. The more abstraction, the better. Abstraction = less knowledge of the collaborating entities. There will always be some coupling, but it is favored to reduce that coupling to its purest form.

framework OO design debugging

2008-06-17T11:59:00.000-07:00

I got my developer app working today. This is my new app. that is utilizing pure OO techniques. It is still a shift for me, as i struggle, i see this more. Think in terms of objects, encapsulated objects, that contain their own data. Pass around a reference to this object, rather than passing along pieces of data by value. How does the object serve the application? Does the object know anything about what application is using it (lets hope not). Let the object take care of itself, keeping its own state and not reaching out to other objects (loosely coupled).

Its not ok to create just tiered applications anymore. I am thinking now more about objects and their state, relationships and bus. logic (which object should it belong, bean, service, DAO/Gateway) and even if i need a bean or service for an object. Could the entity be served by an existing object. I *should have less services than actual beans, as the application progresses. Its ok to start with the 4:1 (entity in your domain has bean, service, DAO, Gateway) - but this is a guide,not a rule! As Sean Corfield said, dont create an anti- pattern.

Anther problem i was running intois the mach-ii framework masking the errors (that i created first in my listener, then in my service, then in my DAO). The experience of stepping through the event flow is always valuable, but the framework was not helping by reporting a very unhelpful message. Is the framework really to blame for masking my mistakes? I think without a framework, i would have at least had a better path to follow regarding where CF was failing (in the listener, service, DAO/Gateway or somewhere else.

Anyway, i have worked my way through the problem. I have a listener that is handing off to a service. The service method requires a struct(listener passing in event.getArgs() ), takes the arguments passed in and calls a private method in the service that instantiates a new object and used the setter methods on that object to update with the arguments passed in from the listener. When the private method is complete creating and updating the object, it passes it back to the main method, who then calls the DAO to it its work. The resulting object reference passed back by the helper method is used as an arg to the DAO. Passing by reference, not value.

This is a big leap for me. I am not passing around a bunch of data, but rather an object reference that is resp. for keeping its own data. Object = encapsulation of its own methods AND its own data.

Im still not sure if my service is real smart, but i am passing by reference now. In my DAO create method, i will keep the validation logic around the actual SQL insert. This is keeping with the fat bus. ready object (non anemic).

Design Patters (official)

2008-06-14T06:32:00.000-07:00

Gleaning from Sean Corfield presentation.

Pattern: Composite View
A composite view is a view that includes other views

Patterns have four parts:
• Name - the common vocabulary
• Problem - “forces” that determine when the
pattern is applicable
• Solution - a template for solving the problem
• Consequences - “pros and cons”

APPLICATION / onApplicationStart()
is a singleton pattern (once entity accessible from one place)

problem (trade off) is breaks encapsulation when object x needs to reference some application scoped variable. A solution is to use something like CS, that injects object X at instantion with the application scoped variable (which is no longer application scoped at this point).

A common problem

I have components that make up my user
security logic but I don't want to expose them to
other code, in case I want to change how its implemented.

Create a new component that has a simple
API that calls the security components.

Think in terms of trade / offs (pros and cons) a pattern has both! For example

Application code no longer needs to know about the
internals of your security system (+)

Application code can still get at the “low-level”
components if it needs to (+/-)

Some redundancy of methods between the API and
the underlying components (-)

Pattern - Facade ( common very helpful)
Problem - as a subsystem grows, it becomes more
complex with a large number of smaller objects

Solution - introduce a single component that
provides a simple API to the set of components
within the subsystem

Consequences - shields clients from the inside of the
subsystem, reducing complexity and coupling; does
not prevent access to subsystem if needed

Often only one instance of a facade is needed(singleton)

Pattern Name: Front Controller - like fusebox or machii or global index, each of these frameworks is a front controller pattern.

Problem - need to apply consistent logic across all
requests in an application (security, layout etc)

Solution - route all requests through a single file that
decides how to process the request

Singleton and Facade refer to objects, most design patterns are focused on OO design

Consequences - centralized control, easy to change
how requests are handled in a consistent manner,
moves logic out of individual pages into controller
(which can become complex)

cfinterface specifies the methods a component provides (API) but not how they behave. cfcomponent *implements* the interface to specify the behavior. An interface can have many implementations. But duck typing is more powerful and appropriate for
ColdFusion - onMissingMethod() lets you implement any methods dynamically.

-- Sean Corfield

However, this is starting at the wrong end. When you
learn patterns by focusing on the solutions they
present, it makes it hard to determine the situations in
which a pattern applies. This only tells us what to do
but not when to use it or why to do it.”
-- Alan Shalloway

Creational patterns
Abstract Factory, Builder, Factory Method,
Prototype, Singleton
Structural patterns
Adapter, Bridge, Composite, Decorator, Facade,
Flyweight, Proxy
Behavioral patterns
Chain of Responsibility, Command, Interpreter,
Iterator, Mediator, Memento, Observer, State,
Strategy, Template Method, Visitor

Frameworks are designed to solve common problems
• Application frameworks usually implement several patterns
• Front Controller - everything goes through index.cfm
• Model-View-Controller - segregation of the presentation and
business tiers

ColdSpring
• Chain of Responsibility - each “aspect” calls methods on the next
“aspect” until the underlying business object is reached
• Identity Map - cache of objects accessed by “id” (bean name)
• Proxy - same API as your business objects but intercepts method
calls to execute before, after or around “advice”

MachII 1.5

2008-06-13T10:53:00.000-07:00

When we upgrade our machii framework code to version 1.5 (released a year ago) there are several changes to note.

First, our existing code should not be effected. Although when i tried this briefly a couple weeks ago, i had a problem with one of the application controllers that was using a .dot notation in the event names. For example; in one of our sub-app controllers, most of the event names look like this;

event-handler event="somename.somethingelse.somethingelse" access="..."/

I have posted this question in the machii google group to see if any known problems with this notation exist.

Also, i have been running across the concept of a "bootstrapper" file or process in a number of blogs recently. The bootstrapper is the start-up routine or file that is responsible for doing application startup configuration. In the old school, no framework world, this would be the index.cfm file. I used to call this the driver, from my days as a procedural programmer. CF also has long supported the notion of an Application.cfm file, work done here has the application scope. With machii, there is the concept of the Application.cfc file and the index.cfm file. Prior to version 1.5 or machii, there was often setup code in the index.cfm file, including the include of the actual framework. In mach1.5, this goes away and no code lives in the index.cfm file, it all goes in the Application.cfc, which is actually extending the machii framework.

When we upgrade the machii framework code to 1.5, we will have to be careful to move that important bootstrapper info from the index.cfm file to the Application.cfc file.

When looking critically at this new bootstrapper file, think in terms of these areas:

application wide properties
machII specific properties
public functions, like
onRequestStart

Once this is done, we should not have too many other issues, then we can start taking advantage of the new 1.5 features, like the include functionality, that will allow us to break up the controllers into smaller pieces.

Where to put listeners and model code

2008-06-13T07:11:00.000-07:00

I ran across a blog discussion today about best practices regarding locations of mach-ii listeners -vs- model code.

A summary.

Listeners are not part of your model layer, so keep them separate from the model code.

Put listeners into a /listeners folder.

Put model code in a /model folder.

In the model layer, some suggested organizing the cfcs like this:

/model/Beans
/model/Services
/model/DOA
/model/Gateway

This is know as grouping by functionality.

Most of the expert opinion (Matt Woodward, Peter Farrell) favored this approach for the model layer.

/model/busObject/

where the bean, service, DAO and Gateway objects were grouped by type. Since these objects comprise the abstract concept of a package, store them as a package. This seems more intuitive, as other programmers come into the application, they will take the approach of what bus objects are there and see what pieces of that package exist.

This is a quote from P Farrell "Otherwise, you are breaking objects into
directories based on object type (pattern/functionality of the object)
instead of the object's purpose (having to do with "user" stuff). This
is counter-intuitive as a developer would have to scan through a
"beans", "gateways", "services" and "daos" directories to see if the
User (bean) has a corresponding service, dao, gateway, etc.. Much
easier (and it makes more sense in the long run) to group by object
group instead of object type (pattern/function). "

A ColdSpring conversation between Mex and Lex

2008-06-11T11:12:00.000-07:00

A hypothetical conversation between, a lesser experienced developer, Lex, and a more experienced developer Mex.

Lex, "what the heck is coldspring?"

Mex, "a framework that helps manage the model layer of your application"

Lex, "whats a model layer"

Mex, "the part of your programming that contains the bus. logic used in the program"

Lex, "how do i know if i have a model layer? and what is the bus. logic"

Mex, "does your application follow the MVC design pattern?"

Lex, "whats MVC?"

Mex, "a way of building your application so the view code is separated from the database and bus. logic code"

Lex, "i think we follow that, i have only really worked on the view side, thats coldfusion .cfm files, right?"

Mex, "yes, cfm files are usually a big part of the view layer, if your using ColdFusion. The model layer which contains your bus. logic are stored in coldFusion files called CFCs. The CFCs are the classes, like in Java."

Lex, "so what does ColdSpring do again?"

Mex, "Coldspring managers the model layer and helps with the relationships, or dependencies that exist between CFCs that collaborate in your model layer".

Lex, "You mean like a service or manager CFC that uses a DAO or Gateway CFC?"

Mex, "exactly like that. The service component or CFC is dependent on the DAO and Gateway to do its job. The way that is typically handled is when the service object is created, it has an init method or function that is called that creates the other objects it needs. In a larger application that has lots of services, this can become a big headache to keep track of."

Lex, "I think i heard some of the other programmers i work with complaining about this and how you have to open a bunch of files to track down what is being created and where."

Mex, "right, CS reduces that complexity by putting all that object create code into a single file or container. That file is responsible for defining all singleton objects in the application."

Lex, "instead of putting create object code in the init method of the service for the DAO and Gateway, you put it in a coldspring file? I could do that for all the services in the application in this one file?"

Mex, "yes and yes"

Lex, "Is the coldspring file magic?"

Mex, "sort of, seriously, its just a xml style file, its really not that complicated, once you understand what its doing"

Lex, "ok, im in, lets get down to some nitty gritty"

Mex, "i thought you would never ask"

Mex.....

CS is a framework, a black box, with a lot of code that you never touch, you simply use it. If you are using a framework like mach-ii, fusebox or model-glue, you have specific "plug ins or hooks" that connect CS to your model. Mach-ii has a plug-in architecture that connects CS to your application.

You write a little code upon application start that executes and creates an object pointer to the black box (CS). Then you use the CS object passing into it the file path to your bean definition file to load the definitions. Each of the beans (objects) is loaded in the application scope. This is really the only file that CS interacts with.

If the object that you are creating has no dependencies, its very simple to create the object with a xml style notation. If the object needs arguments passed in upon instantiation, use the arguments parameter to pass that data along. If the object has dependencies on other objects, use the tag to inject the dependency into the parent dependent object. Think of this as an "inner-bean". If the injected object is only used by the parent object, then define the collaborating objects like this:

bean id="someService" class="somepath.someService"
property name="someGateway"
bean id="someGateway" class="somepath.someGateway"
/property
/bean

When someService is created, it is injected with the someGateway object. The someGateway object is only available to the someService object. Sometimes, the object needs a more global scope, so other objects can reference it as an injection.

If the object being injected is already defined, use this notation to inject:

bean id="someService" class="somepath.someService"
property name="someGateway"
ref bean="someGateway"/
/property
/bean

The difference is that you are not injecting a new object

property name="someGateway"
bean id="someGateway" class="somepath.someGateway"
/property

but are injecting an existing object

property name="someGateway"
ref bean="someGateway"/
/property

ya dig?

More to follow.

Anemic Domain Model

2008-06-10T12:20:00.000-07:00

I was reading an article by Sean Corfield in Fusion Authority today. I have read this article before, but my brain was not ready to grok it, today, it grokked.

The main concept is that too often we load up bus. logic in the service object instead of the bean or value object where it belongs. If you think critically on this, it makes sense that since the data and methods of an object are encapsulated into the value or bean object, so too should the bus. rules around it.

The anemic model is one where the value beans are just containers with state and getter and setter methods - not much else, the bus. rules are stored in the service object.

Sean makes a good point that many of our web applications are getting record sets, presenting in a collection, hiding detail, proving details about one record when requested, not alot of bus. logic to fill up our value beans. But, a good candidate is validation logic when dealing with single or groups of recs, rather than putting that logic in the service, leave it in the value bean - let it live along with the data and methods that it works on.

I recently completed grokking why bus. logic should be in the service and not the listener (model layer, not the application). I supplemented my understanding by going through a few of the older listeners and moving bus. logic out of and into related service object. Perhaps i will iterate again, moving small amount of logic from the services into the beans.

Lets turn those anemic value objects into rich domain objects!

hard core refacoring

2008-06-06T10:21:00.000-07:00

I have spent the past 2 days retooling the model layer of a mach-ii application.

I have renamed numerous listeners and moved then into a new listeners folder. I am really trying to promote the idea of model and application autonomy.

/listeners/ objectNameLister1, ... objectNameListerx

/model/objectName/ service, bean, DAO, Gateway

Each time i renamed a listener, i did a careful search of the controller to update all instances of the old listener name. In some cases, this was only a couple instances, in others, there were many. This also gave a sense of what parts of the application are more widely used.

In a few cases, i renamed a manager that was really a listener, moved it into the listener folder and created a new service cfc. The new listener should only speak to its registered service, so i had additional refactoring to do in the listener. I updated methods that had knowledge of the DAO and Gateway moving that into the respective service. This supports best practices of the listener being coupled to the application and bus. logic living in the model layer, not the listener.

Think about the model layer as application agnostic. Your model layer should be usable by another application. Imagine there is no mach-ii framework with listeners to invoke services. Another application may want to use the objects in your model layer. I moved ALL knowledge of DAO, Gateway and other services from the listeners into their service. The service is the king of the jungle, not the listener. The listener just passes things along.

There were a few listener methods where i left bus. logic in place, but that logic is dealing with announcing of events, making it application logic, which belongs in the listener NOT the service.

Changing the location of the listeners required me to update the path in one place, the mach-ii listeners configuration. If i changed the location of the model classes, i had to change the path of the object invocation (init) method in the service, DAO and Gateway. After doing this a few times, i really stated to see the beauty of the coldSpring layer, which encapsulates this type of change into a single entity, the coldSpring.xml file. I also saw that some of the objects are not taking advantage of the coldSpring framework. These are candidates for coldSpring.

When i encountered listeners and services that had an empty configuration or init method, at least in terms of object creation, and i would see pointer references in class methods, i knew those pointers were defined somewhere, who would have knowledge of such pointers? I also noticed a set method that accepted the object itself at the bottom of those classes. Each of these things is a clear indicator that there is an object management framework in play.

I am still getting my head around how coldSpring is doing things, i thought i would deploy all these changes first, then work on a coldSpring deployment separately.

Things are jelling now, jellin like a felon, architecturally speaking.

Evolution of a MVC application

2008-06-04T10:05:00.000-07:00

I have been tasked the honor of bringing others into or up to speed with a big MVC application. That's ok, i used to be a teacher and trainer, part of my brain enjoys the mentoring role.

I have been studying the architecture of the application, doing some reverse engineering for awhile and have a little summary i would like to share. Blogging this stuff helps me internalize and forces me to think more critically.

In the beginning our application did not use services. Most entities were created following the

Bean
Manager
DAO
Gateway

design patten. Which is fine, except the managers are actually the listeners, they are extending the mach-ii framework listener. All of these files are located in the root of the application in the model folder. Object instantiations to the DAO/Gateway occur in the managers (listener) constructor. The manager is trying to act like a manager (service) by creating its dependency objects (DAO, Gateway) in its constructor. Thats fine, good practice.

As the application grew, real managers started appearing, but not in the model folder (that should just be listeners) in a org. path. The idea of the org. path is to promote the concept that the model or bus. layer is application agnostic. It should not live in the same file structure as the applications listeners. Ill buy that.

The managers, playing the service role, live in the org path along with the other depenency objects, DAO, gateway and Bean (value bean). The managers (services) are responsible for instantiating their dependency objects (DAO, Gateway and bean). The listeners in the model path are only instantiating their manager or service object.

As sub applications start appearing, listeners are where they should, in the model layer and in a couple cases, the related bus. logic (bean, service, DAO, Gateway) appear in a folder beneath the model layer. This is ok, but does not seem to promote the idea of reusable model layer components or agnostic model layer.

In most cases, the listeners are instantiating their service object in their constructors while the service is instantiating their dependent objects in the init functions.

Eventually, ColdSpring was introduced to start managing all these object and dependency object creation. ColdSpring is a framework that abstracts the knowledge of dependencies from the actual objects. Ill study more on this as it appears some objects are not yet utilizing this feature.

Most of the application is following OO practices, meaning that object references are being passed along to service and DAO funtions that are requiring them and using the reference to the bean to handle updating or persistence requirements. Gateway functions are typically accepting values, not references and returning queries.

Some of the application functionality, like the stuff i wrote, is using object wrappers but is too often using procedural pass by value and not object reference. It was not until recently that i really started looking critically at this and reading in blogs why this is problematic.

As i continue to stretch my brain and teach others about this application architecture, i will continue to re-factor and implement OO practices.

Refactoring with on eye on patterns

2008-06-04T06:13:00.000-07:00

I have been looking with a different eye at existing code in our applications. Refactoring code is an important part of any programmers job. I hear the stats about 75% of programmers time is spent maintaining existing systems. That seems about right to me. I have spent a lot of time the past month studying design patterns and best practices for CF developers, since the excellent CF Objective conference in May.

I have been looking at listeners in our mach-ii application and their managers (services) with an eye for moving bus. logic out of the listener and into the service. We actually had a cfc that was named a manager, but was actually a listener, it was extending the machii listener framework and was referencing event args. but did not have a service layer at all. I have been refactoring, renaming the manager to listener and creating a service layer between the listener and DAO/Gateway. It has taken me a long time to really get my head around why we would need all these layers, but i think its finally starting to jell.

I have spent lots of time in blogs, tutorials, books and existing code, learning from the experts, standing on the shoulders of giants, as my former co-worker liked to say.

I will continue looking at the listener and moving bus. logic out and into the service layer repeating the mantra "the listener only passes data to the service layer", its a traffic cop, not a problem solver. The listener can contain logic that directs the flow of the application, but not any logic that pertains to the bus. objects. The bus. objects are application agnostic!

I woke up this am thinking and repeating this to my 11 year old son.

"The bean is a container, that holds data and instructions about something, an object". When the application needs to reference the data or behaviors of the bean, it asks the service layer to do it. The service layer instantiates the bean and passes references to the bean into DAO which will operate on the bean." In others words, a reference to the bean is passed along to service who then passes where it needs to. Any functions that manipulate the data stored in the bean do so by reference. A DAO method requires a object be passed in and references the attibutes of the object via the argument reference passed in."

We are no longer passing values around from one function to another, but rather passing references to a bean.

Evils of debugging tiered software

2008-05-30T08:53:00.000-07:00

Typically, one of the payoffs of a tiered MVC designed application is ease of maintenance. I'm not so sure awhen it comes to debugging. If you are familiar with the application architecture and the application is consistent in how it models objects then the debugging is easier.

I just spend about 3 hrs trying to solve a bug that i introduced while refactoring. I am refactoring some code in a pair of collaborating objects a listener and a service .

I am moving bus. logic from the listener into the service. My listener instantiates the service in its configure method. I created the problem in the one of the service functions, but the error was being reported by CF in the listener constructor at the line number where the instantiation to the service was being called. Eventually, i was able to track the error down in the service function that was using the same variable name for both an argument and a locally vared variable. The error was reported correctly but it took me way too long to figure out that the reporting of the error in the listener constructor was caused by a function in the service. Seems obvious in hindsight, that the listener constructor was failing because it was creating the new object that had to parse the entire cfc before it would create a new instance of itself.

Moral - if the error is occurring in a constructor or init function, then look carefully down stream into the instantiated objects.

Listener -vs- service layer

2008-05-27T13:19:00.000-07:00

Ok, ive been feeling this question for awhile in one of our main applications DataMentor. We have a machii implementation around the application. I am seeing more clearly the reason that we should put our business logic in a service and not a listener. The listeners are part of the application, and our service layer should be application agnostic. I can look back at early design decisions and see bus. logic in the listeners, and even listeners that were playing the role of service or manager. As we build new features into DataMentor, we can follow the best practices of services -vs- listeners and we can continue to re-factor code as we make smaller changes to legacy logic.

Here are a few excerpts from some respected machii architects, Sean Corfield and others.

"If you built a service layer that is independent of the framework that orchestrates actions taken against the model and then you built one or more listeners that mostly just delegate to that service layer, you'll be in good shape."

"Don't think it won't happen to you! I guarantee that you'll find yourself putting a Flex front-end on a legacy Mach II application at some point and you'll wish you too had done a better job of separating your business model from your listeners!"

"Right, a web service front end will also show the same issues. And just to be clear, Flex, Flash and Web Services all rely on the model portion, the CFCs, and not Mach II (or Model-Glue) which is why separating the framework from the model is so important."

See full discussion here.

This is from the machii developers guide on listeners:

Mach II interacts with the Model portion of your application using components that extend MachII.framework.Listener. In a simple application, all of your business logic might be implemented in such listeners but this approach does not scale well with increasing application complexity because, amongst other things, it introduces a tight coupling between the elements of your business logic and the Mach II framework.

You are much better off ensuring there is only a thin layer of coupling between the framework and your application - if necessary, create new components that extend the Mach II listener component, whose sole purpose is to communicate those events to the components within your business model. In other words, try to isolate your business components from the framework components as much as possible: only listener components should know about the framework; only listener components should access Mach II properties; only listener components should announce events. The core business components should know nothing about Mach II and have no dependencies at all on the framework.

In our cfobjective class last month we had a spirited discussion about this. One of the principles i recall was the listeners job being to pass along data to the service layer. The only logic that should be in the listener is logic pertaining to program flow. The listener could announce other events, reference controller properties and set event arguments. When it was done doing these things, it simply handed the event args off to the service. The listener knows nothing about the model layer and the model layer knows nothing about the listener, excepts the names of methods exposed via the API.

Design Patters - more details

2008-05-27T12:21:00.000-07:00

Design Patterns in ColdFusion

Content paraphrased from http://www.jroller.com/page/kwiersma.

I keep coming back to these patterns because I support a large application that implements all of them and have been asked to share my knowledge. This is the knowledge! Granted, there is a lot of business logic in the application, but the architecture of the application follows closely the the principles found in these patterns.

Beans ( Business Objects or Value Objects)
DAOs (Data Access Objects)
Gateways (Data Gateway Objects)
Services (Manager Objects)

The Bean

Typically represents a specific entity in your model

Carries "encapsulated" data between the different layers of your application

like a structure, instead of directly accessing data with a key you call a method

Helps organize data structures instead passing structures around ad-hoc

Has a consistent and simple interface (Controllable API)

Has methods called getters/setters (aka accessors) to access data [getFirstName() / setFirstName()]

Might be composed of other beans

Easily created with a code generator

DAO (data access object)

DAOs only interact with one row of data via the primary key

Used to save/load objects from data storage

A DAO could interface with: Database / Legacy persistent data storage (XML / Text File)

Usually have ScRuD method that take a bean

(ScRuD - Save | (create) | Read | (update) | Delete)

Gateways (Aggregated Data)

return one or more rows of data

Typically returns a cfquery object

Rarely it can return a bean (Querying by User/Pwd)

Performs functionality that may affect one or more rows

Services: (Kings of the Jungles)

Contains your business logic:

Bean Validation / Creation

Application specific business logic

Save / Load / Delete from DAO (via the facade pattern)

Gateway Interaction (via the facade pattern)

Usually depends on a DAO and Gateway

Services can consume other services (very social)

Value objects, Services and Objects Frameworks

2008-05-12T07:23:00.000-07:00

Still internalizing.

Suppose in your application you deal with assessments, standards and resources. Each of these entities would be modeled by a value bean and each of the value beans would have their own service which would have its own DAO and Gateway objects.

A quick review of the value beans reminds use that each has its own constructor method that returns a reference to itself (passing by reference). This provides a complete blue print of the object, with attributes and methods to the requesting entity. Best practices suggest requiring as little as possible to instantiate a object. Define the arguments as optional with default values. Each value object has matching getter and setter methods for each attribute defined by the value bean. The setter methods do not return any values or references, they simply update a instance value. The getter methods return a granular value, string, integer, boolean (passing by value).

A quick review of a service object reminds us that the constructor method also returns a reference to itself. The constructor method would likely have object instantiations to the dependent DAO and Gateway objects and methods to call the DAO and Gateway methods. The service would likely have a utility methods that would create a new instance of its value bean
, which would return a object reference. The service may also contain other utility type methods like data validation on a form. The service methods will likely contain your business logic or rules and may need to reference data in other value objects. Remember to think of your services as the social entities in your software ecosystem. They are the glue between your application and model layer and contain most of the business specific rules that your objects must obey.

In this example, suppose the assessment service needs to know something about the standard bean, it would need to talk with the standard service, now the assessment service needs to instantiate a pointer to the standard service. Suppose the assessment service also needs to know something about the resource bean, now the assessment service must instantiate a pointer to the resource service. This type of dependency is common and can become difficult to manage and debug when things go wrong. Architects often ask who's job is it to keep track of these things? Why does service a need to create pointers to service b or c and vice versa for objects b and c needing pointers to services a and b. This is complex and tricky and has given rise to model layer managers. The model layer managers, like ColdSpring or Livewire abstract knowledge from the service layer. The model layer manages the creation of objects and their dependencies. These objects are all singletons and need only be created once during a given session.

design patterns - A walk through

2008-05-09T08:45:00.000-07:00

I may be a little redundant here, but it really helps me to write it down, and if im blogging here, i am forced to think and articulate a little more critically.

This week, I am walking through a sample application provided by the good folks at cfobjective. I have my eye on the familiar data patterns and how they are implemented in a typical CF application. The application is not using a model manager like ColdSpring or LiveWire, nor is it using a application framework like machII, fusebox or coldbox. You could say its a little more clean this away and allows you to focus on the design of the objects (beans) and its interactions with its service, the application and model layer.

The application is following the MVC pattern and is using a service layer to interact with the DAO and Gateway and a facade to encapsulate the session scope.

The application.cfm file is creating the service object and other app. level setup work. The creation of the service object in the application scope allows it to be avail and used for the creation of a value or bean object and subsequent writes to the persistence layer via the DAO and Gateway.

The init() method of the service object is returning a reference to itself after it creates objects for both its DAO and Gateway. This is a case of the service object having state and knowing about other objects. If there was a model management tool, it would be responsible for keeping the state or dependencies, also referred to as CFC wiring.

The service contains all the methods to both the DAO and the Gateway. The service also contains the method to create a new value bean, which returns an instance of itself. In other words, the service is not only responsible for speaking to the data layer, but also for creating instances of the value beans that it is servicing.

If you need to create a value bean then find its service and call its public method that returns an instantiation of the bean. You are not returning just data like a string or a query, but the entire object, including the methods that are avail. in it. If you need to reference or update part of that value bean, then use its avail. getter or setter methods. This is clean object notation and usage.

For example, lets say we are dealing with a person bean or object.
A user has supplied details via a webform, those details have passed the submission filters and a new person object has been created and its attributes updated via bean setters.

cfset variables.person = CreateObject("component", "Person").init()
cfset variables.person.setFirstName(form.firstName)
cfset variables.person.setLastName(form.lastName)
cfset variables.person.setAge(form.age)

Next, call a addNewPerson function in the service, passing in the object reference and do a little error checking prior to calling the DAO function;

cfset variables.errors = application.personService.addNewPerson(variables.person)

If no errors result, call the addNewPerson function and require the object be supplied.

cffunction name="addNewPerson"...
cfargument name="person" type="Person" required="true" ...

If everything is in order, call the createPerson function, passing in the object reference, which will call the related DAO function.

cffunction name="createPerson" access="public"...
cfargument name="person" type="Person" required="true"
cfreturn variables.dao.create(arguments.Person)

In the create function of the DAO, require the person object be passed in and insert the record using the getter method for the person to get the actual value to write into the table.

cfargument name="Person" type="Person" required="true"

cfqueryparam value="#arguments.Person.getFirstName()#
cfqueryparam value="#arguments.Person.getLastName()#

This is a change of thinking for me, not easy, since i have treated CF in a procedural manner, where i am simply passing in args by value, not by object reference. I am trying to get my head around the benefit, which is trying hard to hide itself behind the added complexity, maybe its not really more complex, im just conditioned to think the other way and so think it more complex.

Design pattern DAO -vs- Gateway

2008-05-08T09:12:00.000-07:00

I thank the GOF (gang of four) authors, Matt Woodward, Brian and Sean Corfield.

nuggets as follow

right off the bat, we realize this is not trivial stuff,

"Designing object-oriented software is hard, and designing reusable object-oriented software is even harder."

define a pattern:

"An object that encapsulates access to an external system or resource."

"Pattern: Bridge. Intent: Decouple an abstraction from its implementation so that the two can vary independently."

I agree with Matt Woodward, who says;

"The DAO and the Gateway, from a pattern standpoint, serve exactly the same purpose. They both encapsulate access to a database. The Gateway pattern is used by many ColdFusion developers to contain methods that handle multiple records. The DAO, on the other hand, is used in many ColdFusion applications to deal solely with single records; many ColdFusion DAOs contain only create(), read(), update(), and delete() methods (affectionately referred to as "CRUD")."

This is an excerpt from the mach-II devlopers guide, this version written by Sean CorField and provides great differenciation of the gateway and DAO design patterns and how they should be used. I have struggles to see this, even to explain it, but Sean seems to nail it down very well. Specifically the part about returning query sets from gateways but objects from DAO.

--- Begin quote from the Mach-II Development Guide ---

There are two basic patterns of access to persistent data within most applications:

aggregated access - reporting, searching, listing multiple rows,
per-object access - creating, editing, working in depth with a single row (object).

ColdFusion has a great built-in idiom for dealing with the first type of access - the query - which is an efficient way to manipulate (potentially large) sets of data rows retrieved from a database (or other data sources, since you can easily create a query object and populate it with your own data). When you are dealing with aggregated access, it does not make sense to convert every row returned into a fully-encapsulated object (CFC instance) when all you are likely to do with the data is display a few fields with a link to a detail page that will focus on the selected row.

On the other hand, when you are focusing on a single row it usually does make sense to work at the fully-encapsulated object level since you are usually interested in object behavior at that point. This is also the level where you need the standard CRUD (Create, Read, Update, Delete) operations.

Recognizing these two basic patterns, you should design your components accordingly by providing separate components for each pattern. This is best explained through an example:

If we have a business model object called Order, then we would provide an OrderGateway component for aggregate access and an OrderDAO component for per-object access (or build the per-object access into the Order object - but see below).
The OrderGateway component would provide methods like findAll(), findWhere(), findByID() and they would all return standard query objects (even findByID() which returns a single row).
The OrderDAO component would provide CRUD methods like store(), load(), update(), delete() and they would operate on a specific Order object exchanging data via getters/setters on the Order component or via some sort of snapshot of the Order's data, e.g., a bean: the Order component could implement methods like getSnapshot() returning a bean and setSnapshot() taking a bean as an argument - the bean containing the core persistent data for the Order object. Sometimes a more direct data transfer between the business object and the data access object is needed for performance reasons (or because the application can 'trust' the components to exchange less encapsulated data, such as a struct or some opaque data structure e.g., the Memento design pattern). Such optimizations are beyond the scope of this document.

Separating out these operations from the business model object helps it stay persistence-neutral. The gateway components can be optimized for retrieving large record sets, caching etc. The DAO components can be optimized for dirty data updates, pooled object access and so on. Again, the details of these optimizations are beyond the scope of this document but providing for the two distinct patterns of data access will get you started on the right road.

--- End quote from the Mach-II Development Guide ---

This wisdom i am paraphrasing from Matt Woodward blog entry, read entire post.

I like knowing that my DAOs deal with CRUD and that's it.

Gateways, on the other hand, are far more nebulous and end up changing much more during application development. I find that I add, remove, and alter methods in my Gateways pretty regularly right up until the application is complete. My DAOs, on the other hand, are built at the outset and they just sit there doing their job.

I also like knowing that when I call methods in my DAOs, they take in an instance of the object with which they are concerned (i.e. the bean) and don't return anything since they're operating directly on the objects passed in. Gateways, by contrast, typically return query objects or, when necessary, collections of beans. Some suggest that if you don't return a collection of objects, we aren't using this pattern "properly." Says who? Fowler? Sun? Maybe in Java the convention is to return a collection of objects. In ColdFusion we have the query that is efficient and easy to use. If all I want to do is loop over a query and display the data, and I don't need to interact with each individual object, why on earth would I make things more complex and less efficient just so I'm better meeting another technology's definition of how a Gateway is supposed to behave? Pure nonsense. When I need to deal with each individual object in an aggregate dataset, I can quite easily return an array of CFCs. When I don't need to do that, I won't bother. Some call that bad programming; I call it practical.

A paraphrase of a Sean Corfield post as response to this post,

"I still maintain that in ColdFusion it makes sense to keep per-object operations separated from aggregate operations because ColdFusion provides a wonderful abstraction called "query" :)

With the rise of ORM frameworks, it makes even more sense to keep "DAO" and "Gateway" separate because the ORMs replace the DAOs completely but only partially replace Gateways, if at all."

Leveraging Design Patterns

2008-05-08T08:12:00.000-07:00

Design patterns (DP) are helpful, especially once you start to see them in action and recognize them as such. DP convey standard ways of solving problems encountered by software architects. Once you have build and maintained applications for awhile, you see "cowboy coding" for what it is, lazy or perhaps uninformed approaches to solving problems. The MVC pattern is one of the first that you need to grok or get your head around. This mature pattern promotes solid tiered or layered programming where the key parts of your application are separated (data, bus logic and presentation). Design patters are not a solution to a problem but a way of viewing the problem and seeing its solution.

Do not be discouraged if you do not immediately see the payoff or even the need for a pattern at first, these are not always obvious and take time to internalize before you see them or the payoff in following or implementing one.

ColdFusion has evolved into a OO language that lends itself to design patterns. If you use cfinclude in your programming then you are already following a design pattern of reuse. If you see the benefit of putting code into a file and sharing that file in multiple places, rather than retrying the code in each place, you are on your way to being a better programmer or architect.

Singleton Pattern - Some objects only need to be created once during the life of the user session, objects like services or application setup services are called singletons. They do not have to keep any state. For example, if i am tracking site visits in a log file or DB, i would only want a single record of that visit, not each time the user does something during their visit. When a user logs into a system, their information is retrieved and stored only once during their visit.

Factory pattern - Just give me what i need and its dependencies. I build objects and their dependency objects. If i am creating a DAO or Gateway object, then i will create also its service object.

Facade pattern - a front end that encapsulates dependencies with object dependencies. When creating a API or interface to my objects, i don't need to share all the details about how things work, just how to use it. The facade is a happy public face that hides the real complexity of the object.

Data Access pattern - data access objects like DAOs only know about the persistence layer or database. The data access pattern often includes helper methods to simplify the way the service layer see it and calls it.

SOA architecture

2008-05-08T07:22:00.001-07:00

I attended cfobjective this month, great conference. One of the sessions i attended was ColdSpring by Chris Scott. He gave a very conceptual overview of SOA principles. I would like to internalize these better, so ill put them into my own words.

Here is the wikepedia definition of SOA. These principles are relevant to OO design in general. Try to build your CFC's in such a way that they can be used by more than just the application you are currently working on. Its easy to develop tunnel vision and only think about the task at hand when building and creating CFCs. It may be a little easier to think only in the moment, but that is junior league.

Think instead of who else could use this object and if someone else where to use it, what do they have to know about it. Think of the object as a small part of a larger system or environment. Think ecosystem and one plant or animal in that system. With that mind set, consider these principles in more detail.

Encapsulate - which means hide the complexity of its inner workings from the rest of the ecosystem.

Think black box, others do not need to know how it works, just that it does.

Think happy face to the rest of the world where the face is the API or interface. The API should show all interested parties how to interact with itself, what questions it can ask of it or what services it provides to the ecosystem and what information must be provided for the request to be understood and carried out by the object.

Try to keep the knowledge of the environment out of the data access objects and only operate on data passed into it, do NOT rely on data that exists somewhere else, like in application or session scope. No reaching out.

Loose Coupling - This means minimum dependencies on other things in the environment. Let each thing be self sufficient.

Objects in general have inherent dependencies, especially data service objects like DAOs and Gateways. Try to minimize these dependencies and even put them into a single place, like a object management service, like ColdSpring. At least then the coupling is managed and defined all in a single place and does not leak into the service layer.

Contract - This is an agreement that exists between two objects that interact.

Think of this as a handshake or agreement that defines how communication occurs. This contract exist between two objects and should not change without informing both parties.

Abstraction - objects hold logic that is not exposed - only a contract is required to use it.

Object a says to object b, i would like to call your method "get widget" where you require me to provide a widgetID. Object B says ok object a, you asked a question that i understand and provided me with the correct ID, so here it is - don't worry, i wont tell you about any of the gory details about how i completed this request for you. What? you want to know what else i can do for you? Ok, here is my API.

Re-usability - a holy grain of software design.

Write code once and try to use it as much as possible. Some objects are inherently not too re-usable, like listeners and view files and controllers - they are all part of a specific application.
The service layer and it dependent DAOs and Gateways are better candidates for reuse (IMHO). So, try to keep the knowledge of the environment out of the data access objects and only operate on data passed into it, do NOT rely on data that exists somewhere else, like in application or session scope. No reaching out.

Composition - collection of like services.

This is the has a relationship that is referred to in UMLing. This is also how many APIs are wired together, via packages. Packages are like minded services.

Cohesion- a service, object or method is good at doing one thing.

Do not try to be the doing of all things. Think in terms of small and numerous, not few and beefy. This is applicable to object design and method design.

Discover ability - the service should be able to be found.

Especially if it is a public service, it should be findable. Using the hint property in CF is a good way to expose the intention of the object.

Object differentiation

2008-05-07T11:51:00.000-07:00

Thanks again to Sean CorField for his great explanation on this topic. I will try to explain for my own internalization. Objects are the heart of a OO system, the way we see and understand their similarities and differences informs how we build them.

There are two types of objects that we model in our CFCs.

1 - Value objects (beans)

Things, nouns (person, place or thing) that make up our domain.

Value objects or beans are the traditional objects that represent things in your domain. For example, one of our applications is called DataMentor, these things comprise its domain,

assessments
resources
users
standards
institutions
scores
examples

Each of these value objects has getter and setter attributes that allow the outside world to see or update them. Each of the value objects has a constructor method that initializes the object and sends back a reference to it. The constructor methods usually also sets the values of the attributes referenced by the getter, setter methods.

Typically, each value object has a service object that is referenced by the application who requests to communicate with it. Remember that value objects are not very social, they only like to be spoken too by their own service. The service is the more social of the two, it likes to talk to its own value bean but also to other services too.

Value objects have 'state' which means they change within a session (the time a person spends using our application). In our application, we use state assessments. If a teacher is looking at different assessments, each time one is chosen, its 'state' should change, the details of the assessment would come from the database and the getter methods for each of the attributes would be called, updating the state of the object.

In our application, a user chooses an institution, a request is made to the database to get the details of the institution. Then the institution service is called to update the state of the institution value object (bean). The service calls the DAO which calls the setter methods for the institution value bean. This process of getting and updating institution details via services, DAO and value beans is repeated whenever a new institution is selected.

2 - Service or Infrastructure

These objects are singletons and have no state. They exist to serve the value objects. They are created once and do not change during the user session, used per-application. They may cache data, because once its state is created, it does not change, requests to refresh itself do not occur.
These objects live to serve the value objects in step 1. If a value object needs to be written to a database or refreshed from a database, the value object speaks to the service layer which speaks to the data access layer which speaks to the database.

Service layer objects are social, they like to speak to other objects, like listeners, controllers, data access models and other services.

There are inherent dependencies between the value and service objects. A value object needs a service object, a DAO needs a service object and the DAO object may need a data source object. These dependencies are difficult to manage, a object management framework like coldSpring can help. A common problem is tight coupling between the objects which means knowledge of each other is required to operate.

Often we use design patterns like Factory Pattern to solve common problems like this.

The Factory Pattern

A factory makes things, like widgets, wadgets and objects. The factory knows about dependencies and manages them. The objects in your application DO NOT need to know about each other. The factory creates the objects and the dependency objects. This pattern reduces coupling between dependent objects.

The question arises, who's job is it to know about the other. For example, who's job is it to ensure that when a service calls a DAO, that the DAO object exist? Typically, you see code in the constructor of the service that creates the object to the dependent DAO. This builds coupling between the two and forces the service to maintain application state, which is a best practice no no. Since the service object has a natural relationship with its DAO or Gateway, a better example might be the service needing information from another object, not its own. How does the service know if that object exists? Whose job is it to know this? Let the factory pattern implemented in a framework like ColdSpring manage the dependency and object creation.

coldspring

2008-05-07T09:40:00.000-07:00

One of the challenges of a larger OO application is tracking and managing the state of objects. I think in many cases objects are created when they dont need to be, but the developer is not sure or cant find the scope of the current object, so they instantiate a new one (guilty).

Following OO best practices like loose coupling (minimal dependency among interacting objects), promotes object creation and managing of its own state. In other words, I better be creating a object pointer to other objects that I depend on. The classic case is a DAO or Gateway data access object that has a service that manages it. The data access object has a dependency to the service layer. Without the its service, the application could never use the data access object. This dependency is often managed in the constructor method of the service. When the constructor method is called, object pointers are created to the data access layer objects.

If your application consists of a lot of objects, then lots of these type of dependencies are created and lots of object instantiation calls are made. Enter coldSpring.

Coldspring is itself a framework that plugs into another framework, like mach II.

ColdSpring helps to manage all this object instantiation and dependency stuff. The creation and dependency relationships are removed from the service layer and abstracted away into a coldSpring configuration file, that is registered in the mach ii controller file.

Read this article and follow others from this blog.

machii framework

2008-05-07T08:56:00.000-07:00

Mach II is framework that is designed to help manage the complexity of large application design. Mach II is the first OO framework design for Cold Fusion. Fuse Box is an earlier Cold Fusion framework that was more procedural or linear, using circuits and actions.

Mach II uses a XML based notation that uses a central controller as the road map for the application. The controller (/config/mach-ii.xml) holds definitions to other parts of the application, like listeners, filters, plug ins and view files. The main workhorse of the controller is the event. The application has lots of events, each of which contains all the "work" needed to complete the event request. Each event is like a small little autonomous part of the application. Events lend themselves to web development because almost every action taken in a GUI can be thought of as an event, like clicking a button or choosing from a list or clicking a link. The directions needed to complete the request are encapsulated in the mach II event.

The mach II controller file has listeners, filters and plugins registered as part of its configuration. The Listener, filter and plugin registrations are conceptual pointers to CFC files in the application. Best practices suggest that the listeners be registered to Services.

Filters and plugins are special types of CFCs that can be registered within specific events to automate frequently needed code, like login check.

The controller also has a properties section that contains hard coded values that are used and referenced throughout the application.

If the event requested needs data then a listener notification is made and a service manager is called, possibly with some arguments or parameters (data needed to process the request). The service or manager would call into the data access layer which would then in turn call to the persistence layer or the database. In many cases, the data is then returned from the database to the data access object to the service back to the controller who stored the result in an event argument (variable) that is then consumed or displayed by the presentation layer or view file.

MachII implements this type of MVC design patten and is specifically designed to work best with well defined objects that adhere to these principles.

Event arguments are event specific or scoped variables defined in the event that are available to the listeners and view pages to help control flow or make decisions during execution of the event.

software design ecosystem

2008-05-07T08:25:00.000-07:00

Thanks to Sean Corfield for his excellent breakdown and discussion of this topic. I would like to internalize these concepts more by writing about them in my own words.

I like the ecosystem analogy that shows the relationship of the parts of a software system or application. The ecosystem has discrete parts that function independently from the system, but also contribute to the overall health of the entire system. Each role plays its part and contributes to the general health of the application.

In the software ecosystem, there are parts such as a database (persistence layer), the model(data layer), with its data access objects like DAOs and Gateways and their services, the controller (road map to the application and manages requests and directs program flow) and the presentation layer (view files or GUIs).

Specifically - the controller has registrations or pointers to the presentation files and to the listeners that then point into the model layer. The listeners speak to the model layer via a service layer. The service layer is not really part of the application aside from being registered in the controller. The service layer should be application agnostic (like Sgt Shultz of Hogens Heroes fame - "i know nothing"). If the service layer only worries about the data layer beneath it, and not about maintaining state for the application, it is much more reusable to other applications and follows design best practices by modeling loose coupling.

This tiered ecosystem promotes individual health in each discrete part but also promotes the overall health of the system. Healthy organs = healthy body.

Internalizing - software design

2008-05-07T07:40:00.000-07:00

I attended the cfObjective conference where lots of good new content was presented. The sessions were packed with details and concepts. To really grok or get something, you must internalize it, put it into your model, see it the way your brain likes it. For me, writing it down is the best way to achieve that. I also like to talk out loud, even more than just thinking about it in my head. Strange i suppose, but verbalizing does help, writing helps more. This is one of the main motivations i have to blog stuff. One of the primary concepts at any software engineering conference would be around OO programming. Object Oriented. That means thinking about things in your problem domain as object, not data containers. I work in education, so i see things like, assessment exams, scores, resources, standards and assets. Think of them as objects that have attributes that define them and actions that they do. Think of the attributes as things that describe the object and the actions as things the object can do. Think of the object and what it does as its interface. The actions start to inform the interface. Think of the interface as the way other objects, including you, see the object. The interface becomes like a public face that is exposed to the outside. You and other objects can talk to and modify the object through its public face.

Design patterns

Once you start to build objects you see commonality among them and the need to predict or manage their interactions. Design patterns help the architect to build predictable manageable scalable solutions. In other words, use patterns to help build great flexible code.

design patterns

2008-05-06T12:32:00.000-07:00

I recently attended the cfobjective conference. Blogging helps me internalize concepts presented, so here goes.

First thanks to Kurt W, Peter and Matt Woodward for the workshop in machii. Also, Sean Corfield for the excellent description and illustration around design patterns.

Why design patterns?

Promote tiered development, which promotes the separation of parts of the application. The bus. logic is separated from the database logic which is separated from the presentation logic. This makes the application easier to troubleshoot, support, add new things to etc.

A very common design pattern is MVC

Programmers can work on different areas of the same application at the same time. One programmer can work on the bus. logic while another is working the presentation layer while a third is working in the database.

Less experienced programmers will typically not see the value in the tiered approach to software design. They will put the logic or code into a single of set of files, grouping together database, business and presentation layer code or logic. This approach is adequate if the application is a one time shot, never to be added to or updated again. If the application grows, the code becomes more difficult to maintain and troubleshoot as new code and logic is added. If a new programmer comes on to maintain, more difficulties arise because there are no standards followed.

More experienced programmers see the pay off and need for a well tiered application. As new requirements come along and new programmers are introduced to the application, code separation and predictability become more valued.