Well then, why don't you have your base panel provide methods that generate the individual components, with methods that implement composite behaviors involving groups of components.
Your constructor can call the component-creation methods to assemble the component hierarchy to match the HTML. Then, when you want a panel with a different hierarchy you subclass the panel, override the constructor to create the 2nd component hierarchy, and provide the new panel its own HTML page. If you don't like overriding the constructor along with the HTML, then you can build some sort of configurable constructor-constructor. /Frank -----Original Message----- From: Martin Makundi [mailto:martin.maku...@koodaripalvelut.com] Sent: Tuesday, November 09, 2010 6:55 AM To: users@wicket.apache.org Subject: Re: Free wicket from component hierarchy hell Hi! > Isn't this exactly the reason we've got CSS? It's just the buzz, not the reality. Unfortunately often CSS "doesn't quite cut it: * http://blog.iconara.net/2007/09/21/the-failure-of-css/ > HTML shouldn't really be used for look&feel and the size and placement of > components can perfectly be defined using CSS classes. In CSS the actual nesting of components plays a big role (div inside float inside abs top 0px ul relative etc.). If you want a professional finish, you will often need to pull components around the layers for different display. Even trying to pull one component will break wicket in strict hierarchy mode. ** Martin > > Matt > > On 2010-11-09 13:34, Martin Makundi wrote: >> >> Also making skins for different devices / screen sizes becomes easier. >> >> ** >> Martin >> >> 2010/11/9 Vitaly Tsaplin<vitaly.tsap...@gmail.com>: >>>> >>>> In simple cases it makes no difference. It makes real difference with >>>> some complex widgets (for example search components) that must be >>>> reused on many pages and they should render differently on each page >>>> depending on how much space and what context they are in. I don't like >>>> duplicating code even if it is gui code. >>> >>> Sounds like the first appealing argument slowly comming out of >>> surrounding fuzz =) > > > --------------------------------------------------------------------- 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
