software design and other stuff

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.