Controller xml file improvements

I've recently gone through an experience with a client that involved many tweaks to the controllers including updating commands, changing data views, field properties and a few sweeping (search and replace style) refactorings. The sum total of this exercise has now almost entirely detached the project from it's roots as a COT web site and it is now a framework without the ability to be edited in the designer since I have made so many manual edits to the controllers and pages. While sometimes a few manual edits and tweaks can be expected, I know there will be technical debt to pay for this but I learned the following:

1. Editing the controllers is far easier than using the designer or parsing through the controllers.log.xml (especially when I have to change several). Why not split the controller customizations into individual files that can be merged with their metadata counterparts? i.e. a project layout that is more flat and allows me to hand-edit the xml which the designer will still recognize. The *.log.xml method is neat but maddening since I don't really need the whole history of what I've been doing to the controllers - that's what source control is for - and sometimes this creates problems such as when an object gets deleted and re-added. It's also harder to read.

2. Re-running the code generator takes too long. I saved many hours of my time by hand editing the controller xml files and checking my changes "live" without having to regenerate. It would be awesome if the designer could read my changes in and allow me to regenerate when an update to the library is pushed out (which we usually need to do for new features). This would be possible with a flattened project format such as

Controllers/Table1.generated.xml (COT generated)
Controllers/Table1.user.xml (my changes)

where both files have essentially the same format but the latter overwrites the properties of the former during deserialization. Consider CSS methodology (specificity and precedence) or the implementation of class inheritance or partial classes.

3. Team collaboration in complex environments is impossible with the current controllers.log.xml file. It's like having one file that contains all your source code (in terms of controllers) which is where all the core of the framework is. Minor UI stuff is nicely distributed into individual files but this is by virtue of ASP.NET and not the COT framework. It's also not merge or source control friendly due to the timestamps littered in each entry and the cryptic, confusing, even redundant tags in this file.

I've said enough about this subject and I've probably said it before but I beg that you please consider what this change could mean to the rest of us trying to collaborate and work more effectively together with COT.

Thanks.
16 people like
this idea
+1
Reply