Posted By : Dan Wilson     September 3, 2009 6:38 AM

I'm presenting on Model-Glue 3 today on the CFMeetup at noon (EST).

We'll look at some of the powerful features of the recently released Model-Glue 3 and use the framework to build out an application while you watch.

This presentation will give you an understanding of how Model-Glue 3 helps you build feature-rich applications faster and more consistently.

More information here: http://www.meetup.com/coldfusionmeetup/calendar/11247016/. You can join the meeting here: http://tinyurl.com/cfmeetup.

Thanks to the consistency awesome Charlie Arehart, the recording of Model-Glue:Gesture for Fun and Profit can now be viewed.

Posted By : Dan Wilson     May 3, 2009 5:13 PM

The ColdFusion community is full of bright people who have built really neat libraries and widgets to make better features and functions for applications. One of my favorites, CFUniform (a rich forms library) lets you build consistent, feature rich forms with very minimal code. I use this library all the time to make my applications snazzier and more maintainable. There are plenty of cool projects I've not yet used and while working on some Model-Glue features this weekend, I had an idea.

See, I've been working on the scaffolding feature in Model-Glue. This feature is a great way to get a jump start on a data-centric application. Simply configure Model-Glue and your ORM of choice and Model-Glue will generate everything needed to Administrate your data. Forms, Lists, delete screens, Bam, it'll generate the whole thing for you in seconds. Of course, the generated code is easily customized to fit the need of the application, but because it is generated from the database, the functionality is generic and the look and feel is somewhat limited.

What if we had a real easy way to plug in some of these rich libraries into Model-Glue? Forms libraries, Ajax widgets, Grids, Rich tables, all these could be as simple as adding a few characters into an XML file. Sounds fun, right?

What I want is to talk to a few of the folks behind some of the coolest libraries to explore how I can provide the best integrations. If you are the author or maintainer of some library or widget, or you use something that you are really fond of, let me know by leaving a comment. We might be able to work together to provide some really neat, useful functionality for the community.

Posted By : Dan Wilson     October 23, 2008 10:09 AM

We on the Model-Glue team have put together a simple survey and want to hear from you. Even if you aren't using Model-Glue or Frameworks or OO at all, your views are important to us.

How long will it take?

We've all taken long and boring surveys with endless questions requiring 1-10 rankings on sundry topics like "How much do you prefer crunchy peanut butter over creamy peanut butter?". Model-Glue is all about making things easy for developers and this survey is no exception. This survey was tested with several monkeys from the North Carolina Zoo. Each monkey was able to complete the survey and give quality answers, all within a 20 minute period. The way we see it, a reasonably intelligent ColdFusion user like yourself should be able to complete the survey in 10 minutes.

Would you kindly give us 10 minutes of your time for the Model-Glue Survey? We promise to read all answers and use the answers for the good of the framework.

No monkey's were harmed in the making of this Blog Post.

Posted By : Dan Wilson     December 17, 2007 10:00 AM

Model-Glue is a very powerful and robust ColdFusion Framework. When solving application problems with Model-Glue there are recurring solutions that work well for particular problems. Up until now, one would have to troll the various blogs hoping the right keywords unlocked google to reveal a proper solution. While effective, this method is also time consuming.

Todd Sharp has developed and released the Model-Glue cookbook. Following the common cookbook format, this timely and relevant application will hold collective wisdom on how to use the Model-Glue framework for fun and profit.

If you want to learn more about Model-Glue, please check the Model-Glue cookbook for interesting tips and solutions for everyday programming. It even has an RSS feed for you!

If you are a Model-Glue expert, or you have found some interesting solutions with Model-Glue, share them with the simple Entry Form. Adding an entry to the Model-Glue Cookbook is easier than blogging and you get full credit.

I admire Todd Sharp. He is an effective community leader, generous with his time and efforts. I mean, look at what he has done in just the last 3 months:

• CFEmmys
• Snip-a-thon contest
• PPTUtils Project
• cfsnippets.org
• Model-Glue Cookbook

Todd gets my vote for Most Deserving of Adobe Community Expert Status

Posted By : Dan Wilson     December 13, 2007 6:36 PM

Duplicating code is Bad! When designing software, take great pains to avoid duplication of code. After all, if an application has a lot of duplicated logic, or cut/pasted processes, it is very easy for parts of the system to get out of wack. A small tweak here, a short change there and next thing you know there are bugs and inconsistencies galore.

As software engineers, we are trained to spot and avoid this duplication. There are whole mantras dedicated toward this end (DRY Don't Repeat Yourself). There are whole books dedicated towards refactoring out commonalities for the goal of improving software quality. This is a very important topic and duplication is one of the easier Code Smells to uncover.

Sometimes the same warning flags will pop into mind when working with an XML driven framework. "Should I really duplicate this line of XML repeatedly in my application?" and "Am I designing my application effectively?" are thoughts the reasonable programmer has. After all, if duplicating code is such a poor idea, why is duplicating XML configuration any different?

The reason it is different is what the underlying XML represents. It represents Code! Code that has been written and tested and debugged Code that performs vital purpose in your application. We aren't duplicating this code, we are duplicating a reference to the code. A type of shorthand, if you will.

If, for example, you have functionality for checking for an authorized user, and such code is wrapped into an XML snippet like this:

You would be perfectly fine replicating this line of XML wherever you needed User Login Verification. The line of XML is very simple, with a clean syntax and very easy to implement without error. When the rules defining User Login Verification change, simply update the single section of code referred to by the XML snippet.

Properly designed XML configurations represent complex processes in a syntactically simple manner. So feel good about duplicating your lines of XML. Happy Coding!

Posted By : Dan Wilson     August 27, 2007 8:45 AM

Previously, we connected Transfer ORM into our ContactOMatic application. Now, we will use it to get some things done! The completed files for this exercise are included at the bottom of the post, just click on the 'Download' link.

Using Transfer with MG:U is quite different than hand coding all the data access instructions so I separated out the new Transfer enabled code from the old hand coded bits to help compare similar operations between the two styles. This means the ContactOMatic is not an example of Architectural Purity! Shock! Horror! Gasp!

To make the separation, I added another ModelGlue configuration file, named ContactAction.xml, to the main ModelGlue.xml file through the use of the include tag as follows:

[More]

Download

Posted By : Dan Wilson     July 24, 2007 3:21 PM

Today we will install the Transfer ORM inside our Contact-O-Matic application. To complete this tutorial, you should have the Contact-O-Matic installed and running. If you have not completed this step, please create the database described at the bottom of Series 6 and install the files at Series 10 download link. Test the application by manually adding several ContactTypes to the ContactType table in your database (I chose Co-Worker, Enemy, Friend). Then use the Contact Form in the ContactOMatic application to enter a few contacts.

[More]

Posted By : Dan Wilson     July 9, 2007 1:51 PM

I am going to continue the 'So You Wanna Create a Model Glue Application series. (Thanks Lola ;) For those just tuning in, the Contact-O-Matic is a simple example of a mini-application using ModelGlue and ColdSpring. The tutorials on the Contact-O-Matic go through the code line by line showing how to perform such tasks as:

1. Set up the frameworks
2. Build a View
3. Place your CSS and JS files
4. Create a form
5. Validate a submitted form and persist the data
6. Return success/error messages
7. Resolve CFC dependancies with ColdSpring
8. Create Instance Objects with factories
9. Refactor, as needed

The Contact-O-Matic is not an example of a Best Practices- Enterprise application. This is due to the simple nature of the program. We simply have a list of contacts, a mechanism to add and edit contacts, and a way to remove contacts. As Object Models grow complex in complex applications, it is important to note that there is no perfect Object Model, only the least annoying set of tradeoffs. I want the code in the Contact-O-Matic to remain simple, and so it shall.

Our next move is to integrate Transfer ORM into our application. The next set of posts will cover installation and testing of the Transfer ORM Framework, the inclusion of another 'Contact-O-Feature' in our application as well as some Architectural Techniques.

Posted By : Dan Wilson     March 14, 2007 9:29 PM

Sean Corfield pointed out that using ColdSpring to make instance (throwaway) components is quite a heavyweight approach for a simple form bean. He is, of course, correct. Our ContactFormBean is currently created by ColdSpring. In this series, we will add a factory object that will make our instance beans for us. The factory itself will be configured through ColdSpring as well as the configuration for our objects.

This is a very simple factory. It has three methods, GetConfig, SetConfig and getBean. In turn:

1. getConfig() returns a struct with keys = objectnames, and values = paths
2. setConfig() provides an interface for ColdSpring to set the configuration struct.
3. getBean() gets the path for a specific object from the configuration struct and returns a created object.

Note: the getBean() method runs an init() method on the newly created object. This is considered a convention in CFCs.

To use this instance factory, add the following ColdSpring xml snippet to the ColdSpring.xml file.

Now remove the original ContactFormBean configuration.

Next, open the Controller.cfc file and change each instance (getContactForm, handleContactForm and removeContact) of getModelGlue().getBean("ContactFormBean") to getModelGlue().getBean("InstanceFactory").getBean("ContactFormBean") .

Finally, reinitialize your application and click on the ContactForm tab. You should see your form as before.

A factory might seem like overkill right now, since this is a simple application. However, Factory objects are a good pattern to learn. Our motivation for the factory in this case was to reduce the amount of unnecessary processing incurred by using ColdSpring to make a simple form bean. We could however, expand our factory to take additional parameters and create all sorts of dynamic objects for us.

In a later series, we'll do just that.

Download

Posted By : Dan Wilson     February 20, 2007 8:25 PM

In our last segment we built the functionality to store our contacts to the database. Now we need a way to edit the information because after all, friends can become enemies, and enemies can become co-workers. We have a good structure in place and these changes will be simple.

[More]

Download