There has been a lot of talk lately about various ways of configuring applications. There’s newly available Config.cfc which has a nice intro in the comments on Peter Bells post about XML Configuration files; which also is worth reading. I’m split on this actually. I like how fast you can start up a project using config xml files, but I think the database and corresponding tools to manage the configuration settings is what would be required to have soemone else manage it. As easy as it is for a coder to change an xml file, it’s not always the coder working with the software. I’ve always loved how with phpBB, or wordpress there are little forms you fill out to get started then everything else is through web pages. You can’t store the more complex objects like this of course(not in a standardized way i mean), but simple key/pair values in a database are trivial. Think I’ll try to give that a go tomorrow, but for today is the XML version!

My first attempt at a Model Glue actionpack is about as easy as can be. I think configuration for this pack is more lines than the actual pack — really. Basically it’s a simple way of passing in ModelGlue.core.SimpleConfig objects to a manager object that stuffs them all into the viewstate. From what I’ve seen reading over other code it seems like a good enough way of handling it most the time. A ModelGlue.core.SimpleConfig object can be just about anything — array, structure, simple values, and looks like any combination. The way this works is just by adding in a line to your ModelGlue.xml file like…

And then the big addition comes in your Coldspring.xml file.

<map>
<!-- These are example configurations.  You can change these to whatever -->

</map>

<map>
Some site title
Some site tagline here.
</map>
<map>
Flash
haloblue
yes
no
</map>

Having a bean named ConfigManager is really the only requirement here. If the actionpack is included without that bean set it’ll give an error when the first page is called. By default autowiring setConfigManager will be called on modelglue.actionpack.xmlconfig.Controller.ConfigController with this bean (the structure of config objects). Change the constructor arguments to take in bean references for anything you want available in your viewstate. Whatever you have in the entry-key value in the ConfigManager object will be what you reference it by in the viewstate. For instance, SiteConfiguration here would be accessible through viewState.getValue(“SiteConfiguration”) and the FormConfiguration would be accessible through viewState.getValue(“FormChangedExample”). This will return the SimpleConfig Object, which can then be converted into a structure, or just worked with through the SimpleConfig methods. It’s available now in the public repository at http://svn.adamfortuna.com/public/ModelGlueDev/.

What it comes down to is being able to access those values in the viewstate easily enough…

[cfm]

Model-Glue is up and running!
[/cfm]

Will generate this…

For a few months Teratech has offered downloads of the CFunited sessions videos on their site for a fee, with one sample video free to anyone. Now, however, attendees can download the mp3s of each session as well! I’m definitely looking forward to hearing a lot of the tracks I wasn’t able to make it to. If you went to CFUnited this year, check it out.

I stand by that entry last month about Choice Between Learning and Doing. In October a lot of the Model-Glue code I wrote was in a vacuum after I got started. I saw the basic ways of doing things and for the most part went forward and did them. Two things I learned have much better ways of doing than I initially coded them, one of which directly affects what’s in the svn repo for my little learning-model-glue project LineOfThought right now.

The first I probably should have noticed when I mentioned actionpacks a few weeks ago but slipped my mind. The Coldspring XML for the email service that comes with Model Glue as a sample actionpack is a little snippet that looks like this (cut down to the unique features).

<bean id="EmailConfiguration" class="ModelGlue.Bean.CommonBeans.SimpleConfig"></p>
<property name="Config">
    <map><br />
      <entry key="developmentMode"><value>true</value></entry><br />
      <entry key="developmentEmailAddress"><value>no-reply@localhost</value></entry><br />
      <entry key="defaultFrom"><value>no-reply@localhost</value></entry><br />
      <entry key="defaultType"><value>text</value></entry><br />
      <!-- few more settings... --><br />
    </map><br />
  </property>
</bean>

This is the bean declaration for EmailConfiguration, which is where all the default settings would be. Instead of just creating a structure (a map in Coldspring XML speak) and passing it to the EmailService, it creates a ModelGlue.Bean.CommonBeans.SimpleConfig object and sets the Config variable (variables.config in the the cfc) to this relatively simple name/value structure.Why it would do this and not just pass the struct into the EmailService wasn’t clear at first, but right there it passes it in…

<bean id="EmailService" class="ModelGlue.actionpacks.email.model.EmailService"><br />
  <constructor-arg name="EmailConfiguration"><br />
    <ref bean="EmailConfiguration" /><br />
  </constructor-arg><br />
</bean>

EmailService then has the very simple config settings object available to it with some basic getters/setters. The code to get/set from the SimpleConfig object is an overall clean interface which keeps the EmailService object from having to handle storing the structure for which it might not know anything about. Instead the EmailService can request data from this easily…
[cfm]


[/cfm]

Calling getConfigSetting(“developmentEmailAddress”) then would return no-reply@localhost in this case, where variables._config is set to the passed in EmailConfiguration object. The same could also be done by just calling variables._config.getConfigSetting(“developmentEmailAddress”) within your service whenever you need it.

The second moment of clarity tonight came reading an old blog post by Joe Rinehart about Dynamic sorting with modelglue.GenericList. The generic database calls in ModelGlue are what power the scaffolding feature, so there’s a heads up about how easy to work with they are. What I didn’t know, however, was how easily they could be tied in with the ORM’s gateway methods. Basically, in your ORM gateway methods you’ll have custom queries for anything that might have a few joins and be a little more complicated than your average query. Unbeknownst to me, using the ModelGlue.GenericList (and other Generic* methods I imagine) you can call on gateway methods and feed in URL parameters. This is basically like having the ability to call the query in your model when that’s all you need before going to your view. Previously, I’d assumed you’d have to broadcast an event, make a method in a controller, call the newly created gateway method, add the record to the viewstate and then proceed — so this method saves a decent amount of code. Tip of the hat to Rinehart.