> hmm i do like to separate the components with its own markup and the onces > that dont > > johan >
I would say the division should be different. Component which needs markup (markup is provided either by parent component or is their own) and the ones that don't. Would be very nice if you can easy say, which case it is and easily change it as well. Some components can generate all markup, so there is no need to look for some. > > On 12/13/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote: >> >> I agree with that remark, and like the idea of components attaching to >> markupfiles whatever kind of component they are. However, what we'd >> gain in flexibility by getting rid of Panel (hypothetically), we'd >> loose in clarity. If you wouldn't explicitly instantiate a panel that >> matches markup, how would things work? What if you have a markup file >> that matches the component class and that has both <wicket:panel> and >> <wicket:border> tags? What about a border fragment attached to a text >> field? >> >> It also might be quite tedious to implement. More people have thoughts >> on >> this? >> >> Eelco >> >> On 12/12/06, Petr Sakar <[EMAIL PROTECTED]> wrote: >> > > On 11/29/06, Johan Compagner <[EMAIL PROTECTED]> wrote: >> > >> what makes a formcomponent a formcomponent? >> > > >> > > That, of course, is the main question :) But not an easy one, >> > > certainly not to extract a robust interface from it. The component >> > > like I proposed (but that should have the header stuff included) >> works >> > > fine though, so this might be a better solution than forcing >> ourselves >> > > into interfaces when we're still unsure about what the best are. >> > > >> > > Eelco >> > > >> > May would be interesting to try it from the other end - what makes >> Panel >> a >> > panel ? A lot of components (not only form) can have except its own >> > behaviour the behaviour of panel ... >> > saki >> > >> >
