Wicket team gave us this maven archetype called wicket-archetype-quickstart, which generates simple wicket webapplication. You simply type in your console
and from now on you can explore the vast world of wicket development. You get very simple maven project, with wicket Application object, WelcomePage (hello world type) and simple test that shows usage of WicketTester.
If you starting your adventure with Wicket, this should suffice. But as you get quickly through the wicket basics, you will quickly realize that wicket-archetype-quickstart is simply not enough. Eventually you will finally decide to write your very first webapplication in Wicket and that will be the moment where wicket-archetype-quickstart will shows its weakness.
First of all, wicket-archetype-quickstart is simply webapplication project. There is no business layer, no persistence layer and simply no connection with some backend technology (for example Spring). Of course Wicket is only web framework, however nowadays I can’t simply imagine webapplication without some backend technology, so chances are, you will need one.
Wicket integrates with Spring rather smoothly. When configured, you will get out of the box:
- Dependency Injection
- Integration with JPA
- Open Session In View pattern 
- Transactional tests – one of advantages is fact that all action you made in tests on database are rolledback at the end of each test (regardless of whether test passed, failed or thrown an exception).
However to makes things work, you need proper configuration. Even for person experienced with Spring this task might be troublesome. Take for example dependency injection. You can inject dependencies that given controller needs, as you would do in any other Spring application. However in Wicket all controller fields are serialized with each request and they travel in cache with user session. If you would use @Autowired annotation, you could eventually serialized half of your application context.
Of course Wicket team created @SpringBean annotation, that acts like @Autowired, but is free of just described problems. Yet this proves that integrating Spring with Wicket might be a problem, even for someone exprienced with Spring. Not to mention a fact, that creating such integration (repetitively creating configurations for each new project) would be boring task, that would quickly end up in dull copy-past from one project to another. I would really like to have some archetype that could do all this repetitive and boring actions for me.
Secondly, when creating wicket (+Spring+JPA) application from archetype, I would like to have it already grouped and organized by layers. One layer for domain area, one for business logic (service) area and one for the web part. Ideally I would have some examples that show how to use it. For instance an example that shows how to create dao object , use it as dependency in service object and finally use this service object in controller of my webapplication. This way I would not only have proper structure for my application, but also I would have examples of how to use it.
I belive that examples are very powerful. Whenever I try to use new technology I always go to the examples, try to run them and then I start extending them, while learning new technology at the same time. If examples are good, chances are I will learn how to use the technology in a proper way. In Wicket (+Spring+JPA) application it is easy for me to imagine a junior developer using DAO object in controller area. This is what I would call a bad programming, but if there were no given examples to show good programming, I could not blame him.
Thirdly, Wicket gives robust security support, for both authorization and authentication. However you won’t find usage of it in wicket-archetype-quickstart. Since I’m almost always securing my webapplication and doing it is a simple copy-past from my older projects, why not put it in an archetype?
Last but not least are Wicket tests. They are powerful, but after few months of development in Wicket I believe that they need some conventions, otherwise there might be a moment, when moving some component in markup tree from one place to another, will end up in failing 260 tests (paths will not match). You might find yourself in situation where you have to fix paths in 260 JUnit tests – and that is really not what you would like to be doing.
However there are ways and conventions that help dealing with this problem (where making this 260 tests passed is simply a matter of changes in 3 lines of code), however again examples are needed to show the usage of the convention.
There are few other things I would like to have in my Wicket Application archetype. Useage of CSS file and resourses for example is something that you will see in almost every webapplication. Configuration is simply matter of few lines in your code, but since it is repetitive, why not have it created automatically?
Well, I’m pretty curious what you think about it. Especially people that use Wicket. Do you also believe that wicket-archetype-quickstart is not enough? Currently I’m developing WicketCool project, one of its features will be extended maven archetype, that will try to solve described problems of wicket-archetype-quckstart. Can you think of any other things, that you would like to see in such archetype? What would enhanced your development by automating repetitive, configuration work? Let me know: leave a comment or contact me directly.
More information about WicketCool project soon to come. I can now tell you that the tool reached version 0.6.0-SNAPSHOT, it can be downloaded from the project page (you no longer need to build by yourself) and that I am still extending its functionality. However because I’m doing it by myself, tool develops rather slowly. Any volunteers happy to help, are more then welcome!.
. If you don’t know what Open Session In View pattern is, then I strongly encourage you to google it. To tell the long story short, OSIV pattern helps you to deal with lazy initialized entities, whose values are somehow show to the user. EntityManager is closed after page response is rendered (not before), thus you don’t get LoadLazyException when reaching for entites in the controller.