I'm sorry, I don't know of a good solution for your design problem. But it sounds as if you already have an idea - and I'm sure that if you encourage your colleagues to tackle the problem, you together will come up with even better ideas.
In my experience, it's almost possible to fix an existing legacy system, and almost always also less risky and more viable. And that's because it can be done in small, iterative steps.
- it really being a top priority, acknowledged by your management, (or the willingness of your team to work as professionals against the will of management),
- the resources to do it
- the skills to do it - mainly refactoring skills, to implement the incremental changes in low risk ways, and the skills to write automated tests for legacy code, to support the refactoring
I highly recommend the books "Refactoring" and "Working Effectively With Legacy Code"
Actually, Subversion branching feature was especially designed to satisfy your requirement.
About XML, message files, I don't think there will be a problem because they are text files. Merging is not easy anyway, but you should try it first, for me built-in merging function of TortoiseSVN is good enough.
... I guess there should be many companies which provide a customized version of an application for different customers.
James Clark wrote:Customization is typically driven by configuration data stored in a relational database. This is the best route...as always, data is best stored and accessed via relational database management systems (RDBMS).
Uh - why?
@James: You're surely right that a central database would be a good place to store application wide data. Unfortunately I think this would become quickly impractical in this case because we're talking about XML based view templates which often have to be edited by hand. Of course it would be possible to provide a small tool to upload and download the templates to and from the database but I think this wouldn't change much of the problem as it only shifts the problem from the file system to the RDMBS
Aside from one or two configuration files all the so-called meta-data or configuration data are indeed stored in our RDBMS. But this is not really the problem. In fact it doesn't even influence the view templates directly.
And all this is not driven by some data from the database or something like that, but mainly by the application flow at runtime!
James Clark wrote:
Uh - why?
Because attempting to do otherwise typically creates a variety of maintenance and versioning nightmares.
Unfortunately I still didn't get i, James... I mean, basically I understand what you're talking about but I suppose you should see those "templates" in action to understand my point. They are not only ordinary templates you probably know from other view technologies. Some of these beasts are alive That is they have behavior almost like a piece of code thanks to the magic going on behind the scenes with reflection and the like.
Marco Ehrentreich wrote:Of course you're right, data should be kept in a database
*Everything* is data. Even program code.
Sounds like there is a significant group of design flaws in this "magical" code and all the "wonderful" things that are happening. XML design with a narrow perspective usually results in XML that is difficult to manage.
Information about the behavior related to how the XML structures are formed is what can be stored in database tables. This is how you can achieve efficient customization for each customer with the same application code. You really need to understand what needs to be done and would really need to redesign your current system.
Think about the current conditional logic, parameters, arguments, etc. that currently exist. Then think about how this varies from customer to customer. What is it about "customer" that makes this happen this way or that way?
You would pull this information out of the current code, but still use it in the current code.
There will be a charge for any further analysis ... just kidding