Philosophy & Goals: “Less is more!”
The overarching philosophy of Wicket RAD is “less is more!”, you should not have to write 500 lines of boilerplate code and markup to do something in your webapp if it can be done in 50 lines of code.
Put in other words, the main goal of Wicket RAD is to supercharge developer productivity by letting developers do more with less code when developing web applications (something which Wicket alone already achieves, but Wicket RAD builds further on that).
Wicket RAD will provide a set of Wicket Components and JPA utilities aimed at doing the heavy lifting and legwork for the developer, freeing the developers to do what is important in his/her specific project, rather than write repetitive boilerplate code.
We have been doing webapps for going on twenty years, so by know it should be quick and simple for anyone with a little Java knowledge!
Design principles
In practical terms, we try to achieve the goals of Wicket RAD through the following design principles:
- Do not repeat yourself: If a certain type of problem can be solved with a single solution, only solve it once
- Simplicity & focus: Make the simplest, most compact solution possible. Each class/interface in Wicket RAD should have a tightly defined, specific purpose.
- Flexibility and modularity through composition: Don’t want to use the “full stack” solution, but only the frontend Components orbackend functionality? Be my guest, it should always work. Want a different type of layout for your BeanEditPanel that is not available by default? Just compose the smaller components that a BeanEditPanel consists of in different ways. You should be able to take everything as is, or pick and choose what you want and build the exact thing you need.
- Testability: For Wicket RAD to give developers confidence and empower them to do more with less code, it is imperative that Wicket RAD is properly tested, and can be regression-tested in no time. Therefore it is an aim to have good test coverage of all code, and accept no major contributions unless they come with a satisfactory suite of unit-tests (useful contributions are more than welcome, just make sure it comes with tests).
|
|
