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?


Reply via email to