FreeRoller upgrade on the way!
FreeRoller is down right now, so I'm assuming the upgrade is not just on the way, it is underway. YAY!
re: Rise of the WikiLogs?
Patrick posts about Wiki-blog integration and wonders how Wiki-blog integration plays into the future direction of Roller. Here are my thoughts on that. Roller is first and foremost a weblogging system. I don't want to incorporate a Wiki into Roller, and I think the other Roller developers agree with this, but I do want to make it possible to integrate Roller with an external Wiki.
For now, Wiki-Roller integration means allowing weblog entries to be authored using Wiki syntax, making Wiki links in weblog entries link to an external Wiki, and allowing each weblog entry to have it's own Wiki link to an external Wiki, as Patrick describes.
I'm doing this integration by adding an (optional) Wiki plugin to Roller. I use JSPWiki for the Roller Wiki, so I'm creating the plugin using JSPWiki. I have this working now on my homebox (without code changes to JSPWiki), next, I'll create a Wiki-blog demo here on this site so you can see how it works.
The Coat-of-paint anti-pattern.
Developing a wrapper class or API can be a way to add value to an existing API and can also be a way to isolate an existing API. Wrappers can be very useful, but when applied incorrecly, wrappers can be counter-productive and downright irritating. For example: the Coat-of-paint anti-pattern.
In this anti-pattern the developer wishes to isolate an API behind a wrapper, so he develops a very thin wrapper class for each of the classes in the API. Next, he procedes to use these wrapper classes throughout his code, but because the wrappers are so thin, his code still depends on the concepts, relationships, and often the method signatures of the wrapped API. The wrapper is like a coat-of-paint on the wrapped API, it changes the appearance of the wrapped API but does not truly isolate it.
A better approach would be for the developer to divide his code up into modules or "tiers," with each module having a well defined interface. Instead of isolating the API he wishes to hide behind a thin wrapper, the developer should have isolated the API by using it in only one of his modules.
UPDATE: Another, possibly more difficult, approach would be to develop an abstraction layer over the API that is to be isolated. If you will enventually need to switch out the wrapped API for some other API, then an abstraction layer is the way to go. It is a more difficult approach because, unless the underlying APIs are simple, developing a good abstraction over them can be a challenge.