this is all heading down a very very slippery slope and i dont like it one bit. right now we have clear definition of what is what and how things work.
the only usecase that keeps coming up is for simple wrappers around existing form components when they are used to dynamically generate forms. does anyone have any other practical usecases? it seems to me this is being worked on inside out - it is formcomponent that should be a mixin interface so you can extend by delegation. now that wont happen until wicket 3.0 which is when we will switch to interfaces for multitude of other reasons. for now i accept eelco's hack only because i think it is a necessity at this point in time. but as i said i think the way our markup resolution works now is fine. -igor On 12/13/06, Petr Sakar <[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 One of many solutions would be to use interfaces to give hint to framework, how the component behaves. For example the component can implement interface HasAssociatedMarkup, IsBorder, IsHeaderContributor, ... > 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? Probably wrong markup file. What will happen today if you create such markup for Panel ? > > 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 >> >
