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 [mailto:cmen...@wicketbuch.de] Sent: Tuesday, November 09, 2010 9:12 AM To: users@wicket.apache.org Subject: Re: Free wicket from component hierarchy hell On Tue, 9 Nov 2010 14:21:46 +0200 Martin Makundi <martin.maku...@koodaripalvelut.com> 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. Carl-Eric www.wicketbuch.de --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
