Well, I _am_ composing panels; the issue is the kind of glue I should use for attaching the panels within the page (in lieu of calling abstract methods from my constructor). What method of assembling panels do you have in mind when you refer to “panel composition”?

I suppose one way is to assemble the panels in each page independently; the common panels are reused, but if 50 pages all use the same panel in the same place, I’d be repeating that

“add( new Panel…);”

command in 50 pages. And, I’d have to repeat the HTML containing the panel’s wicket-id 50 times. Not good.

Another approach we’ve discussed is to have the base page assemble the common panels along with dummy panels, and to have the sub-page replace the panels that vary. The sub-page programmer has to look at the base page documentation or code to learn the panels that should be replaced and the variables containing each respective wicket-id. Is this what you mean by “panel composition”?

Suppose I move the base page’s component tree construction out of the constructor into the method:

private void assembleComponents() { …

and add the property:

private boolean componentsAssembled = false;

Then I could add:

@Override
void onBeforeRender() {
if ( !componentsAssembled ) {
assembleComponents();
componentsAssembled = true;
}
super.onBeforeRender(); // Or whatever else I might have put into this method
}

Then component construction would wait until the properties in both the parent and the subclass had been set, and I’d no longer have a problem with calling abstract methods from the constructor. Abstract methods would still tell the subclass what it needed to implement, and each abstract method would provide the proper wicket-id.

Do you see any disadvantages to this approach? I don’t think additional boolean test in “onBeforeRender()” is computationally significant, and it would not prevent me from adding any additional on-before-render tasks.

If it is a good approach, I wonder why the Wicket designers did not create an overrideable called-once-after-object-construction method in the Component class, and tell developers that this is where the component tree should be created.

> Markup inheritance is not a good solution IMAO, as it allows sub-pages to develop only a single part of the parent page.

Wicket is no silver bullet I agree, you have to live with this limitation. But no despair, composition with panels is another technique that works very well.
One more note: Wicket 1.5 will allow multiple extension points for sub-pages.

> Also, it wastefully forces the sub-page to have its own HTML file when all you’re trying to do is to insert into predetermined places a few panels that already contain their own HTML.

Well actually, I was saying it is wasteful to /replace/ components that were already added by the parent page. It is acceptable (within limits) to add components from sub-pages while the associated HTML is in the parent page. The wicket id to use can be given by a constant in the parent page. With Wicket 1.5 this kludge will no longer be necessary.

> My motivation for using the abstract methods was:…

These are very good considerations. However, the underlying mechanism in flawed because you are using java Btw, I went through the same steps before I came to this conclusion.

> What would be a better solution?

The solution is to step away from markup inheritance and only use it for the most basic HTML layout of the page. Instead you can use panel composition. (Note this is what I recommended in the article.)

> It seems to me therefore to be a flaw in Wicket’s requirement that the page hierarchy of components be completely built during the page’s construction.

Strictly spoken, this is not the case. The component hierarchy must be complete before the render phase starts. Therefore you can also add components in an overridden Component#onBeforeRender. You’ll need a flag to keep track if you already did this, or clear the currently present components. Also, you might want to override callOnBeforeRenderWhenInvisible. Don’t use this technique before you have tried to use panel composition.

I’m thinking that if my base class overrode that method to call the “CompleteThePage()” method, then subclasses wouldn’t have to worry about adding “parent.CompleteThePage()” to the end of their constructors.

It seems to me therefore to be a flaw in Wicket’s requirement that the page hierarchy of components be completely built during the page’s construction. The parent page is only going to know about the components that are common to all the sub-pages.

Markup inheritance is not a good solution IMAO, as it allows sub-pages to develop only a single part of the parent page. Also, it wastefully forces the sub-page to have its own HTML file when all you’re trying to do is to insert into predetermined places a few panels that already contain their own HTML.

One alternative is to have the subclass replace dummy components that the parent page built — but you condemn that, too, as wasteful and unmaintainable.

My motivation for using the abstract methods was:

(1) To ensure that no one tries to instantiate the base page (as its component hierarchy is incomplete),
(2) So that writers of the sub-pages would know what components they needed to add, and
(3) So that writers of the sub-pages would not have to look at the base page’s HTML file to discover those components’ wicket-IDs, nor would they have to examine the base-page’s code to determine the container components to which the specialized sub-page components are to be added.

What would be a better solution?

Would you suggest putting into each base page an uncalled “CompleteThePage()” method — which calls the abstract component-creation methods and adds the components to the component hierarchy in the proper places?

With this latter approach, we would then merely depend on the sub-page authors to to know that “CompleteThePage()” must be called at the end of their constructors (the compiler would still ensure that they instantiated the abstract methods it calls).

Of course, in a page hierarchy, the intermediate page constructor would have to call “parent-page.CompleteThePage()” — to distinguish it from its own “CompleteThePage()” method that its children call in their constructors.

It really surprises me that the Wicket community has not discussed this issue already, and that Wicket developers would be satisfied with the weak and ugly “mark-up inheritance.”

Frank: Martin and LeChe gave the correct answer.

Dave, Nick: Thanks!

I think the issue that Erik is referring to has to do with the general problem of calling abstract methods in any class’ constructor. Basically, you are leaking the reference to a incomplete object by doing that and any implementing class (that you might not be the author of) might incorrectly assume that object construction is finished!

The book “Practical Java” is a very good source for this (and similar) kinds of gotchas…

Regards,
Che

@Frank: check http://www.javapractices.com/topic/TopicAction.do?Id=215
I think this is what Erik meant

Look forward to more posts like it.

Cheers,
D

I don’t understand your objection to components created by abstract methods, saying “constructors should not call these.”

Let’s say I have a set of pages each with four quadrants (UpperLeft, UpperRight, LowerLeft, and LowerRight), and let’s say that the UpperRight and LowerLeft are pretty constant across many pages of my application, but the UpperLeft and LowerRight panels vary independently page by page. I would like to create a base page that deals with the two common panels once and for all.

So I create an HTML template with wicket IDs for the four panels in their place. My abstract base page creates and adds all four panels. However, for the UpperLeft and LowerRight panels (which vary across the sub-pages), the base page’s constructor calls:

abstract Panel createUpperLeftPanel(String wicketID);

and

abstract Panel createLowerRightPanel(String wicketID);

in each case passing the actual wicket ID defined in the base page’s HTML.

When developing the individual pages that inherit from my base page, I need no HTML file for the sub-pages — they use the base page’s HTML file. In the sub-page definitions I can ignore the very existence of the UpperRight and LowerLeft boilerplate panels — how is that for information hiding? The only new HTML needed for the sub-pages is the HTML for the individual panels I instantiate when implementing the abstract methods.

When creating the page-specific panels, the sub-page definition doesn’t even need to know the wicket IDs used by the base page — the abstract method provides it. (If I change the wicket ID on the base page, as long as it passes the new ID to the abstract method, the sub-page does not break.)

So what’s wrong with this pattern?