The Heartbeat Project

That is, my MSc project. The aim is to produce a "CMS-generation framework" that should be easy and flexible enough to allow easy extension via subclassing. Ideally, the user should be able of defining a simple CMS in a configuration file, and let the framework do all the work. The produced CMS should be also XML-enabled to allow semantic communication with other systems, with the final target being the framework itself to build "clouds" of systems semantically interoperating and coordinating. I'm following an XP-like workplan, building prototypes and refactoring along the way. The chosen implementation language is Java, for a number of reasons, the first being its good OOP capabilities and its popularity. The first relevant problem was to abstract the item composition, defining how an item is built from simple attributes (text or integer fields, etc) and complex relationships (one-to-many, one-to-one). This way, the framework behaviour could ignore the physical storage and, above all, the language chosen for the final application to be generated. I think I got the problem right when I stopped thinking the relationship was an extension of an item attribute, and chosen the composition way; quoting the Gang of Four's "Design Patterns", to "prefer composition over inheritance" was really helpful. As it is now, my abstract ItemRelationship class links an arbitrary item attribute to a specific item, allowing the one-to-one and one-to-many relationships relevant to the object definition. In the prototype implementation (whose target language is php), this allows to deal pretty easily with the basic stuff like Foreign Keys pointing to other items' ID, and also consider different relationship kinds (aggregation vs. composition). I wouldn't be honest if I say I'm not proud of this result. For the next step, I have many choices to do. The first is, what problem should I tackle? The main ones are to extract relevant interfaces allowing to dinamically switch between implementations (the various scripting languages) and storage facilities (RDMS and XML). i think I'll follow a Factory pattern for the first and a Strategy pattern for the second, but I still haven't made up my mind. More "pragmatic" problems are to build the ConfigurationParser and Outputter classes, basically interfacing the system to the "physical world" of text files. The parser will probably have to wait, because its implementation would have to be refactored very soon; I prefer to build test classes to mimic its behaviour until I won't have defined all the interfaces for the system to expose. The Outputter, instead, should be pretty straightforward, not so much subject of refactoring in the future, and above all, it would already produce an usable output for everyday work. Even now, a tool generating production-ready php classes would be very handy indeed. (This must be one of those moments, when the R&D department comes out with something that is not the original development target, but it's still very useful, and they release it, and then sometimes this small "pet project" becomes something like the original Gnutella client...) I'm afraid I can't release the code yet, for a number of reasons. Maybe this autumn, but not now. It's not I'm shy (I would love to share my results), it's that sometimes the "off-line world" needs prevail. PS: Kudos to Industrie Toulouse for this old post, that has been a companion for my thoughts. I should probably also thank Martin Fowler, but there's enough people already doing that ;) PPS: It seems like using a blog as "research stack", as said by that old fart warrenE about his Blogger-powered site, really works. After all, they have been created mainly for that purpose. Oh, fuck off and die