XLS vs XML

May 8, 2012 at 9:11 AM

Hi,

I like what you've done, but just a small criticism over your choice of xls files for holding the config values.

For small/simple projects this is probably fine, however picture the following scenario - you have a SaaS platform, and due to there being multiple workstreams, there are multiple projects each with their own branches (we currently have 10 branches off our main release branch with a different project team working on each).

Periodically, once a piece of work it completed in a project (which usually involves work across all tiers in the platform), they merge back to the release branch with their code, database and config additions & changes.  Following release, each of the other projects then take the merge into their project branches, and the merge is also merged into the patch branch.  Likewise, we also have the patch branch merging released patches back into the release branch.

The fact that the configs are in an xls file would make that part of the merge a nightmare, whereas an xml file is inherantly text based, and much easier to merge and validate.

I think you should expand the platform to cover loading configs from either xml or xls files so that it can cope with both simple and complex platforms and branching structures. 

Colin

May 8, 2012 at 10:14 AM

Hi Colin,

Thanks for the feedback.

The main driver for using a spreadsheet as the choice of storage for settings was that it allowed you to easily view all the settings in a tabulated view in one screen. ConfigGen is all about easily visibility of settings, so this seemed the natural choice.

However - over time I've come to totally agree with this point about merging that you make - it is a problem that frequently gets in the way for me too and an xml format, for example, should make merging much easier. However, I wouldn't want to trade easy merging for a loss of visibility - the tabulated view is the primary way I spot mistakes in configs.

To this end, one of the other developers on the project is doing a spike on a WPF based editor, that looks similar to the spreadsheet tabulated view, but uses xml as the backing store - this will hopefully give the best of both worlds: Similar settings visibility, and easier merging.

We have also been discussing the ability to then put this editor in the IDE itself, which would mean you can do all the editing without starting an external editor. This then leads on to the possibility of having the IDE regenerate configs (if you wanted it to) automatically when either the settings or the template file changes.

If and when this piece does get completed, I think we would keep the spreadsheet option too, for backward compatibility - but the newer version would become the "preferred" option.

I really appreciate you taking time to email your thoughts - so please continue to do so, and let me know if you think the changes I have described would be good for you, or if you have criticism or suggestions for these.

Thanks,

Rob