While working on an Apache Wicket app, I have some questions.
The example in the user guide(s) tend to put all the creation of the
page's component in the constructor()
https://nightlies.apache.org/wicket/guide/9.x/single.html#_the_homepage_class
However, I'm seeing that that approach has some downsides. For more
complex components e.g. forms or complex panels with many embedded
components (e.g. reusable tables forms, page layouts (e.g. menus) etc).
Sometimes a lot of parameters are passed to the constructor to fill up
the page / component.
There are often cases that some components has various options or
optional components. Currently, I'm handling that by declaring different
constructors so that the basic ones may have less parameters, and where
the options or optional components are needed, they are passed into the
page via constructors with more parameters.
Another downside is a javabean styled component where one can have a no
args constructor. And that the various parameters are updated using
getters and setters methods, e.g. with commons beanutils
(https://commons.apache.org/proper/commons-beanutils/).
I'm thinking about implementing component construction i.e. initializing
the various page components using onInitialize()
https://nightlies.apache.org/wicket/guide/9.x/single.html#_hook_methods_for_component_lifecycle
That means say if the web page codes looks like
public class HomePage extends WebPage {
public HomePage() {
add(new Label("helloMessage", "Hello WicketWorld!"));
}
}
it becomes
@Override
protected void onInitialize() {
super.onInitialize();
add(new Label("helloMessage", "Hello WicketWorld!"));
}
In fact, rather than pages, it is more likely that I use that with
components and override onInitialize().
In that sense, components can be constructed 'javabeans' style say using
a no args constructor and its properties set using getter and setter
methods.
Is this feasible, has anyone done this in an actual app?