As an alternative, suppose that one's non-panel compound component
contained a map from wicket-id's to components.  The hierarchy could be
encoded in a lisp-like string; the component's constructor could parse
the string and create the component hierarchy to match.  The hierarchy
string could be a configuration property that the constructor looks up.

When you want to use the component on an HTML page whose wicket-ids are
embedded differently, set the configuration parameter to the desired
hierarchy string.

So instead of asking, "How can we make Wicket different so that my
problem will go away?" the proper question to try first is, "What is the
Wicket way of solving my problem?"

-----Original Message-----
From: Carl-Eric Menzel [] 
Sent: Tuesday, November 09, 2010 9:12 AM
Subject: Re: Free wicket from component hierarchy hell

On Tue, 9 Nov 2010 14:21:46 +0200
Martin Makundi <> wrote:

Here we finally come to an actual argument about this:

> Panel is not reusable enough because it has its own markup. If I
> override its markup, it stops working.

Frank wrote in another message how to deal with this case. I agree with
him and add: If your new panel is so different from the old panel that
it requires a different internal hierarchy, it's no longer the same
component. Use standard OO techniques to deal with it. Also, think
about whether your component design (as in what parts form a component,
and what parts don't) is correct. Seems to me that in such a case too
many things have been thrown together that should not be together.


To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to