"Do we really think this is that big of a problem that we need to change the whole paradigm of the framework to address it?"
IMO, No. -----Original Message----- From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] On Behalf Of James Carman Sent: Tuesday, November 09, 2010 9:06 AM To: users@wicket.apache.org Subject: Re: Free wicket from component hierarchy hell I think we need to try to put our heads together on this one. I don't necessarily think this approach is the best, but I haven't really had a chance to wrap my head around it yet, frankly. Do we really think this is that big of a problem that we need to change the whole paradigm of the framework to address it? Perhaps you can create a new "container" component that does all of this stuff with some pre-render magic or something? If you want to use it, you can. If not, you don't have to. So, if you're the type that likes this loosey goosey stuff, you basically "wrap" your pages with one of these things to enable this type of behavior. I don't know. This is just off the top of my head. Still not done with my morning coffee. On Tue, Nov 9, 2010 at 9:58 AM, Martin Grigorov <mgrigo...@apache.org> wrote: > I think we have to make a vote whether this feature has to be investigated > further. > There are over 90 mails in the thread and I have the feeling that only > Martin Makundi likes the idea. > > On Tue, Nov 9, 2010 at 3:46 PM, Frank Silbermann <frank.silberm...@fedex.com >> wrote: > >> 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 >> >> > --------------------------------------------------------------------- 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
