You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fortress@directory.apache.org by Martijn Dashorst <ma...@gmail.com> on 2016/12/05 15:16:00 UTC

Code conventions for wicket components

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.

Re: Code conventions for wicket components

Posted by Shawn McKinney <sm...@apache.org>.
> On Dec 5, 2016, at 9:16 AM, Martijn Dashorst <ma...@gmail.com> wrote:
> 
> I've found the coding guidelines and will add them to my Eclipse installation.

Ok, thx

> 
> On Dec 5, 2016, at 9:16 AM, Martijn Dashorst <ma...@gmail.com> wrote:
> 
> As an experienced Wicket developer I found the following things invaluable.

Methinks thou doth understate :-)

and for the benefit of this list, Martjin is author of (what I believe is) the definitive book on Wicket: 
https://wicket.apache.org/learn/books/wia.html

> 
> On Dec 5, 2016, at 9:16 AM, Martijn Dashorst <ma...@gmail.com> wrote:
> 
> 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.

agreed

> 
> On Dec 5, 2016, at 9:16 AM, Martijn Dashorst <ma...@gmail.com> wrote:
> 
> 
> 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).
> 

+1 again

> 
> On Dec 5, 2016, at 9:16 AM, Martijn Dashorst <ma...@gmail.com> wrote:
> 
> 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.

Yes, of course, please proceed with the recommended changes.  And thanks for the clear explanation of intent as well.

Shawn