I've found the coding guidelines and will add them to my Eclipse installation.
As an experienced Wicket developer I found the following things invaluable. 1. put all UI resources that belong together in the same physical location: Properties, HTML, Java, etc files for Wicket components have a 1-1 relationship and should reside in the same folder next to one another. This makes it easy to work on a page or panel because you can see all the resources that are necessary for the page or panel in one place. It makes it easy for other Wicket developers to work on your application as well. 2. Use plain string constants directly as Wicket component identifiers. Wicket component identifiers are typically single use, only relevant to the component they identify for wicket in the Java code and the markup. When you use "someIdentifier" in Java code, it is easy to find the affected markup in the HTML file. When you use a central registry for string constants and use them by reference, it obscures the understandability of the code. Another benefit when using String constants directly instead of by reference is that IDE integration can take you directly to the affected markup and vice versa (1). In your current code base you split the markup from the Java code, and use a GlobalIds for Wicket component identifiers. I know there's some rule in PMD or CheckStyle that says one should only use constant references and not magic numbers nor magic Strings. However in the case of Wicket identifiers they truly are local as long as one doesn't use MarkupContainer#get(String) to retrieve a component from the hierarchy (but then you're doing it wrong anyway) My proposal for the new bootstrapped commander is to keep all resources for a given page or panel next to one another in the same location, and to use String constants directly for Wicket identifiers. Martijn (1) See the Eclipse qwickie plugin, which allows you to quickly navigate between markup and Java code.
