|
I was sold on DotNetNuke when I saw Jim Duffy's two excellent presentations on it at DevTeach, Montreal in June. One of the points he stressed was that as long as you don't touch the core package application code, DNN upgrades are seemless. (This “seemlessness“ is a theoretical concept for experienced developers, of course, but the principal of not touching the core application still applies.) Another benefit of not touching the core application is being able to share code changes.
I was able to spend several happy customizing .Text 0.94 code for four company blog applications about a year ago, adding such things as blog subscriptions so posts would be delivered via email as well as RSS, tying blogs to projects and other data from other systems, re-writing the security code so that any employee could post to any blog, and so on. There is no way--no way--I could ever upgrade those four .Text applications to 0.95, and that's okay. There's no reason to do so.
But I have worked hard to isolate my code changes from the core code base of DotNetNuke, nGallery, and .Text. I don't code as part of a team, so I suppose this principal of isolation or modular coding is an everyday approach for those who do. Hell, I don't even know the proper nomenclature for this design approach. What I did was to create a /DBVT subdirectory in each app and put my additions and changes there, duplicating the folder and filenames of the original code (shown at right.) Where I did have to add code to the base, I was faithful in adding “DBVT Code Block” commenting. I also added a “dnn.config“ file so that any dbvt-specific value could be configured at runtime. More on the specifics another time. |
 |
 |