The most used model in Wicket is the
PropertyModel and its derivatives. This model allows the user to quickly and easily navigate object graphs using string-based property-path expressions, and is used extensively when displaying data or creating forms.
PropertyModel and its string-based expressions are also responsible for adding the most fragility to Wicket code. The standard Java tooling does not support refactoring strings that happen to contain references to java constructs such as methods or fields; thus errors in these string expressions are not discovered until runtime.
For example, the string used in the code below:
new Label("state", new PropertyModel(personModel, "address.state.code"));
will not be updated by the tooling when the getState() method is renamed into getArea() and will thus cause an error only discoverable at runtime.
So why is
PropertyModel used so often in Wicket code even though it causes so many problems? The answer is simple: it is, by far, the easiest and most convenient way to achieve the functionality. We chose to sacrifice robustness of our code for development ease and convenience. What if there was another way to achieve the same, but without using strings?