On Tue, Nov 9, 2010 at 7:36 AM, John Owen <jo...@globalscape.com> wrote: > "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?"
it will not be changing the paradigm. it is adding a new method for you to add components. use it if you want, dont use it if you dont. -igor > > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
