Thursday, February 19, 2009
Object orientation has been the great software success story of the 1990's. If done well, OO programming allows to save on development costs by fostering code reuse and by improving maintainability through reduced coupling. In the next paragraphs, I'll show what is necessary to support these techniques in a web framework and how Wicket has exactly those properties.
Code reuse is achieved through polymorphism and abstraction. Polymorphism allows to share code among object that are almost, but not quite the same. You define a common superclass for those objects and override methods to implement the behaviour specific to a particular subclass. Abstraction, on the other hand, works by allowing an algorithm to treat various object the same, even if they are implemented differently. We call this programming to an interface. In Java, for example, you can call methods on an interface, even if you don't know the implementing class. But this is only possible, if we do not depend on the implementation of the object. In particular, the state representation of the object must be private to the object.
The same mechanism of encapsulation also allows to reduce coupling between modules. If I do not know how an object is implemented, I cannot have a dependency on that implementation, and I'm therefore free to change the implementation without consequences in the rest of the system. The biggest maintenance nightmare is the class that nobody will touch, because the smallest change may have unforeseeable consequences.
Since Wicket components are simply Java objects, it is trivial to apply the OO mechanisms of code reuse to create new components. There is no tag library to implement, and existing components can be customized simply be overriding the appropriate methods. In other component oriented web frameworks, there is usually a clear distinction between creation and use of components. In Wicket, there is no such distinction. You cannot write a Wicket application without creating at least one component: the home page.
Wicket's use of controlled serialization for implementing private component state, plus a couple of associated techniques (markup inheritance or the component id scheme, for example), allows for truly "black box" components. The best prof of this is the usual installation instructions for wicket component libraries: you just drop the jar on the class path. The component needs to do the rest.
I believe that Wicket is a very economical choice of web framework for various reasons. It supports an object oriented, modular architecture in exemplary fashion. That makes code reusable and easy to maintain. The philosophy of "no magic" and the restriction of scope to the realm of web user interface make it possible to understand for the framework on a deep level. Wicket is written entirely in Java. This allows the programmer to debug his web application from end to end. It also makes for a very shallow technology stack: there is simply less code to understand and debug. That in turn expands the talent pool if you're trying to find programmers: you can concentrate on hiring the right people instead of the people with the right buzzwords on their resumes.
I have been complaining on the wicket-users list that more could be done to push wicket for business reasons. In future posts, I'll expand on the above points and try to show why Wicket could be right for your business.
Monday, February 16, 2009
<prefix>:page:version:<path to elmement>:AnInterfaceThe first part is an identifier of a particular version of an object, the second the method to be called. So in a general way, we can understand a request of a Wicket URL as a remote method invocation.
Thursday, February 12, 2009
The same thing happens when you buy DRM-encumbered media. You effectively give up control of the media to the company you buy them from. Let me illustrate: the new car I bought last year comes with a great feature: the audio system has a USB port where you can plug in a stick with MP3s. I quickly put all of my music on and now I'm sometimes embarassed by the crap I used to listen to in the eighties. The point is: my CD collection goes back to around 1983. I can carry that music forward with me as far as I like because I have it in a reasonably open format. If you buy media that are DRM-infested, the seller still controls it. Just remember when Microsoft pulled the approval servers for it's "Plays for sure" scheme.
The point here is: if, as a company, you rely on some critical piece of software, it really makes good business sense to go with open source software. If you rely on closed source software for a critical piece of your infrastructure, you have just outsourced control over a critical piece of your business to someone else. With open source software, you always have the option to take control of the code yourself. Chances are, you're not the only one relying on the product, so the chance of continuing the development over a long period in time is much higher.