LightWire: The Benefits of a Programmable Configuration Object
In this Software Product Line, I may well have 20-30 business objects (each with a controller, service class, DAO, bean and metadata bean) - so that is up to 180 beans right there that need to be described and have their defaults set. Of course, genning the XML would be fairly straightforward, but I like to have a framework that I can work with manually as well as generate for, and I'm not interested in writing 180 bean defs by hand (and that is just for the business objects - ad in controller features, custom data types and all of the other bits and pieces and 400 objects wouldn't be completely unreasonable).
In addition, I happen to want my setup to be smart enough that it'll check for each business object class file in the application com directory and if it doesn't find a custom business object there then it should get the object from the main framework directory instead. I can imagine writing code that would gen XML that would then be parsed by a framework but instead, I do the following in my programatic bean config:
For (ConfigCount = 1; ConfigCount lte listlen(BusinessObjectList); ConfigCount = ConfigCount + 1)
{
// Get current object name BusinessObjectName = ListGetAt(BusinessObjectList, ConfigCount);
// Controller If (FileExistsinApplication("com.controller.object.#BusinessObjectName#Controller"))
{addSingleton("lightbase.applications.#Application.Name#.com.controller.object.#BusinessObjectName#Controller");}
Else
{addSingleton("lightbase.framework.com.controller.object.#BusinessObjectName#Controller");};
addConstructorDependencies("#BusinessObjectName#Controller","#BusinessObjectName#Metadata");
addMixinDependencies("#BusinessObjectName#Controller","#BusinessObjectName#Service");
// Service If (FileExistsinApplication("com.model.#BusinessObjectName#.#BusinessObjectName#Service"))
{addSingleton("lightbase.applications.#Application.Name#.com.model.#BusinessObjectName#.#BusinessObjectName#Service");}
Else
{addSingleton("lightbase.framework.com.model.#BusinessObjectName#.#BusinessObjectName#Service");};
addConstructorDependencies("#BusinessObjectName#Service","#BusinessObjectName#Metadata");
addMixinDependencies("#BusinessObjectName#Service","#BusinessObjectName#DAO");
// DAO If (FileExistsinApplication("com.model.#BusinessObjectName#.#BusinessObjectName#DAO"))
{addSingleton("lightbase.applications.#Application.Name#.com.model.#BusinessObjectName#.#BusinessObjectName#DAO");}
Else
{addSingleton("lightbase.framework.com.model.#BusinessObjectName#.#BusinessObjectName#DAO");};
addConstructorDependencies("#BusinessObjectName#DAO","#BusinessObjectName#Metadata");
// Business Object (IBO) If (FileExistsinApplication("com.model.#BusinessObjectName#.#BusinessObjectName#"))
{addSingleton("lightbase.applications.#Application.Name#.com.model.#BusinessObjectName#.#BusinessObjectName#");}
Else
{addSingleton("lightbase.framework.com.model.#BusinessObjectName#.#BusinessObjectName#");};
addConstructorDependencies("#BusinessObjectName#","#BusinessObjectName#Metadata");
addMixinDependencies("#BusinessObjectName#","DataType");
// Metadata addSingleton("lightbase.applications.#Application.Name#.com.config.#BusinessObjectName#Metadata");
addConstructorDependencies("#BusinessObjectName#Metadata","ApplicationConfig");
};
The fileexistsinApplication() code is just a simple method I added to my bean config for checking whether a file exists within a given application. I also have code elsewhere that actually figures out what data type singletons to create for a given project based on what cfc's are in the appropriate directory so I don't have t configure that by hand at all.
I'm not saying this is the one true way. There are many benefits to an XML based config approach, but there is no way I could create the projects I do in the timeframe I do without my config file (I've looked at the Google Guice annotations style approach but it doesn't fit well for my use case - I'm not looking to reuse beans between disparate applications - only within a single software product line that gens n-projects, so a central config file is actually a little easier for me to work with).
Anyone else playing with this?
In order to create my Google Sitemap XML file, I actually do something (somewhat) similar. I have a google query file and a google xml file. If the query file exists, it feeds the XML file. However, I can use the google xml file without the query (depending on the context). When I build my master Google Sitemap XML, it iterates over all the directories that might have it and checks to see if exists.
This has work quite nicely and I have had NO complaints with it. It checks for file existence and if its there, it includes it. This requires zero configuration and requires only a bit of consistency in directory / file naming conventions.
I would like apply this to actually configuring parts of an application as you have done. I think its an excellent idea.