Moments of enlightenment
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).
[xml]
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…
[xml]
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]
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.
If you enjoyed this post, please consider to leave a comment or subscribe to the feed and get future articles delivered to your feed reader.
Comments
Leave a comment