I’m using Apache Wicket for developing web apps, I have developed a few for the last year and it has been great; today I was looking at a few pages and most of them look like this:
public class MyPage extends MyBasePage
{
public MyPage() {
constructUI();
}
private void constructUI() {
//first build all the models..
IModel aModel = new SomeModel(new SimeObject());
//then build forms, links and buttons like this
Form myForm = new Form("myForm", aModel) {
//notice that the submit logic is not implemented here
private void onSubmit() {
myForm_submit();
}
}
}
private void myForm_submit() {
//handle the form submision here, validation, service calling etc..
}
}
I usually handle the form submission and link/button clicking on separate methods in order to keep the constructUI method as short as possible, most pages have 1 or 2 grids, and 2-3 forms for different actions, for my specific needs and use cases this practice gives me these benefits:
-
The UI can be constructed/deconstructed in different ways (to refactor the markup for example) without having to copy/paste/move-around the whole submit handling logic
-
Having
*_submit,*_clickmethods allows to easily navigate the class using “ctrl+o” (on Eclipse) to filter and find methods
So my question is, if there exists some software pattern that would allow to separate the “constructUI” logic into a different class, or something similar, because some pages are component heavy (even using custom components) and “constructUI” gets too large.
If your pages get big try to decompose them into smaller Panels.
I dont like in your code that you have only one method in the constructor. If it it like this i would omit this method and write all in the constructor.
We use an approach where every component is created within a function and returned from there. This allows us to keep every information about a component in one place. Additionally the name of the function returning the component is the same as its wicket:id. This helps further to better read the code between java and html. Our pages/panels look like this:
public class MyPage extends MyBasePage
{
Form form;
public MyPage() {
form = form();
form.add(submit());
}
private Form form() {
Form myForm = new Form("form", aModel);
myForm.setOutputMarkupPlaceholderTag(true);
return myForm;
}
private AjaxSubmitLink submit(){
AjaxSubmitLink asl = new AjaxSubmitLink("submit") {
@Override
protected void onSubmit(AjaxRequestTarget target, Form<?> form) {
someService.saveSomeEntity(aEntity);
target.add(aFeedbackPanel);
}
@Override
protected void onError(AjaxRequestTarget target, Form<?> form) {
target.add(aFeedbackPanel);
}
@Override
protected void onConfigure() {
setVisible(ifSomeCondition());
setEnabled(ifSomeOtherCondition());
}
};
asl.setOutputMarkupId(true);
asl.add(new SomeBehavior());
return asl;
}
}
Wicket has different cycles for building the component tree and rendering it. Understanding those cycles will help you to avoid creating components in the constructor, which the writers of Apache Wicket consider a bad practice because it can potentially increase the size of your session. Try writing code that puts model objects in fields, puts instantiation in add methods in an overwritten onInitialize method, and sets visibility in overridden onConfigure methods.
public class MyPage extends MyBasePage
{
private Form<MyModel> form;
private Model<MyModel> aModel;
public MyPage(PageParameters parms, MyModel aModel) {
super(parms);
this.aModel = aModel;
}
@Override
public void OnInitialize(){
add(form(aModel));
}
private Form<MyModel> form(Model aModel) {
Form<MyModel> myForm = new Form("form", aModel){
private static final long serialVersionUID = 1L;
@Override
private void onInitialize(){
add(submit());
}
}
}
private AjaxSubmitLink submit(){
AjaxSubmitLink submit = new AjaxSubmitLink("submit") {
private static final long serialVersionUID = 1L;
@Override
protected void onSubmit(AjaxRequestTarget target, Form<MyModel form> form) {
target.add(anAjaxRenderedComponent());
}
@Override
protected void onError(AjaxRequestTarget target, Form<MyModel> form) {
target.add(anErrorPanel());
}
@Override
protected void onConfigure() {
setVisible(someBooleanReturningMethod());
setOutputMarkupPlaceHolderTag(true);
}
};
return submit;
}