Where Should the Automagic Go?
Firstly, the config beans had quite a bit of intelligence to deal with all of the automagic defaults and conventions making the framework a little larger than I wanted it to be. Secondly, I realized that while I was coming up with a good set of conventions it was quite possible that I'd have to vary the automagic conventions used for different use cases which would require me to swap out the base config bean for different projects (Ok, but not ideal).
So, using the principles of encapsulating what varies and the Unix concept of "lots of little applications", I'm trying a different approach. This time I am creating a very explicit and relatively un-DRY XML syntax for describing application parameters, business objects, screens, controllers and the like. It contains a lot more required attributes than my old config methods did. For example, in the past if a property had a title of "First Name" then unless the name property was explicitly set, it was automagically set to FirstName. If an application didn't have a DSN defined it was assumed to be the same as the application.Name and so on. In the new XML syntax, both Title and Name are required for every property and the DSN must be explicitly set within the application tag.
At first this might appear like a retrograde step (first he starts using XML, then he gets rid of his automagic configuration - who is the person blogging and what's he done with Peter?!), but as part of a larger system it starts to make a lot more sense.
Of course, if I was really planning on sitting down and writing the XML config files by hand, this would be a huge step backwards, but because I'm generating them, I have simply moved the automagic out of the framework (which was limiting the framework to a single automagic approach) and encoding it into the generator, making it easier to vary the automagic to use the same framework to generate applications with different conventions.
Thoughts?
What happens when you make a change to the generator? Do you now need to regenerate those XML files for every project?
Is it true that no one will /ever/ change the XML by hand? If they do, and you regenerate, what happens?
As soon as you move to having a generator, you now have two moving parts you need to keep synchronized - changes to the generator would have to continue to meet the XSDs (a validation step in the generator calling the framework XSDs would probably be advisable). Equally, non-backwards compatible changes to the framework would require changes to the generator and then the re-generation of any sites wanting to use the new version. In practice I'm not so much looking to change generators as potentially being able to have multiple generator configurations (perhaps different template sets) so you could generate different projects based on different automagic preferences without having to tweak anything manually. As for the whole changes and versioning thing, expect to see LOTS of stuff from me on that in the fall. I'm hoping to present at the DSM conference on DSL evolution which wll look at how it applies to everything from APIs and database schemas to in-language DSLs and XSDs.
As for changing XML by hand, they are free to, and all changes will be lost on next regenration. It's like asking what'd happen if someone edits the core Rails files. Fact is it'll probably break - that is life. The trick is provide people with lots of valid extension mechanisms, and while I could parse and diff the XML to allow people to hand modify it, I buy into the Lye comment - XML is useful but should never be touched by human beings. Thus I'm not going to make the XML files a manual extension point, but will merge extended data into the XML files using a combination of configuration and automagic.