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
