Frameworks, XML and duplication
Duplicating code is Bad! When designing software, take great pains to avoid duplication of code. After all, if an application has a lot of duplicated logic, or cut/pasted processes, it is very easy for parts of the system to get out of wack. A small tweak here, a short change there and next thing you know there are bugs and inconsistencies galore.
As software engineers, we are trained to spot and avoid this duplication. There are whole mantras dedicated toward this end (DRY Don't Repeat Yourself). There are whole books dedicated towards refactoring out commonalities for the goal of improving software quality. This is a very important topic and duplication is one of the easier Code Smells to uncover.
Sometimes the same warning flags will pop into mind when working with an XML driven framework. "Should I really duplicate this line of XML repeatedly in my application?" and "Am I designing my application effectively?" are thoughts the reasonable programmer has. After all, if duplicating code is such a poor idea, why is duplicating XML configuration any different?
The reason it is different is what the underlying XML represents. It represents Code! Code that has been written and tested and debugged Code that performs vital purpose in your application. We aren't duplicating this code, we are duplicating a reference to the code. A type of shorthand, if you will.
If, for example, you have functionality for checking for an authorized user, and such code is wrapped into an XML snippet like this:
2 <message name="verifyUserLogin" />
You would be perfectly fine replicating this line of XML wherever you needed User Login Verification. The line of XML is very simple, with a clean syntax and very easy to implement without error. When the rules defining User Login Verification change, simply update the single section of code referred to by the XML snippet.
Properly designed XML configurations represent complex processes in a syntactically simple manner. So feel good about duplicating your lines of XML. Happy Coding!
There are no comments for this entry.Add Comment Subscribe to Comments
Thanks for the comment. I am not exactly sure what you mean by "Basically XML are for configuration settings, Having your business logic in XML is not exactly appropriate to the tech level."
Can you elaborate on why you have a different point of view?
Thanks again for making this distinction Dan - it's a point of view I hadn't considered until now. Before this I was desperately trying to avoid duplicating code and XML, to the point that I tried to the user validation into the onRequestStart function (with event detection).
I now see that specifying when an event needs authentication in the XML is a perfectely acceptable method and alot 'cleaner' than having to detect the event string in the onRequestStart block.
With this method, if the event strings ever change the application won't break - lovely.
Basically XML are for configuration settings, Having your business logic in XML is not exactly appropriate to the tech level. Might point of view is different because I like to have app-setting in xml rather my business/flow process.
For better explanation and implementation I would suggest to ColdBox.