More on Classless Objects and Intelligent Scaffolding

Creating a newsletter system? Well, you may need to write custom code to publish newsletters, but the admin list, view, add, edit and delete functionality should just write themselves based on declarative metadata. For a simple add or edit form all you need is a list of properties to include within the form (user might have first name, last name, email and password, for instance) and to have a custom data type for each property so you know password is a “password” data type, email should be validated as an email address and so on. In that way, you can have nicely optimized form fields, validations, transformations and display rules (like displaying a US phone number as XXX-XXX-XXXX and providing three separate form fields for entering it into) automagically.

Because of this it is very easy to auto-generate a large percentage of your views and controller and model methods. The question is how you implement this . . .

One approach would be to use code generation to create (for instance) a DAO, service method and controller for each object. The only problem with that is your code isn’t very DRY, because other than a few properties, the code in each class is just about identical. Sometimes this is required because of language limitations (such as if you want to use cfqueryparams which have to be hard coded), but most of the time you can just use base classes to do the heavy lifting and then just extend them so a NewsletterDAO will extend BaseDAO, just setting a few properties and then calling the base methods (until you want to customize the way that a method works in a way that your generator/framework doesn’t automagically handle for you). For more on this, see my article in FAQU 2. It explains how to use base classes as a basis for either dynamic programming or application generation.

But if you just have a few properties and are calling base methods, why bother cluttering up your application with a physical NewsletterDAO.cfc at all?! Why not just create a virtual NewsletterDAO by adding a NewsletterDAO bean configuration to your LightWire configuration file and set the class path to instantiate the BaseDAO instead? Of course, if down the line you really need a NewsletterDAO (because you need to write a method that can’t be declaratively specified), you can still create the NewsletterDAO that extends BaseDAO and then change the class path in LightWire to point it to the NewsletterDAO and you’re done.

With this approach, because the unique behavior of the NewsletterDAO (as compared to the UserDAO or ProductDAO) is driven entirely by constructor properties in LightWire, all you need to do is to add a new bean definition in LightWire with the appropriate constructor properties and you don't need a physical NewsletterDAO.cfc at all.

I’m just finding this is allowing me to prototype applications even faster and more importantly (because I could easily generate empty NewsletterDAOs and the like) it keeps my code base extremely clean as I can much more easily tell what classes have truly custom behaviors and which are just completely specified through unique constructor properties in LightWire as I only have physical class files for classes that have truly custom methods.

The only real limitation to date I've found is that I need to either have or not have a physical class for the IBO, DAO AND Service for any given business object if I want to be able to use package protected method as that is dependent on physical class paths, but the way I'm going I may end up giving up the benefits of package secured methods for the greater benefits of being able to make my objects much more independent of physical cfc files, giving me a lot more options for dynamically generating my objects.

Thoughts?!