There are also implementation issues that need to be considered. Currently the model is stored in a way that it doesn't take any place when not used. Having multiple models is rare, however, having one model that can (but doesn't have to) be used is more common imho. Wicket is kinda optimized for the later, so if you don't use the model there is no runtime cost associated. If we didn't have "default" model slot this would be more difficult to achieve.
-Matej On Wed, Jun 4, 2008 at 12:37 PM, James Carman <[EMAIL PROTECTED]> wrote: > On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius > <[EMAIL PROTECTED]> wrote: >>> it all depends, on how and what you're developing. >> >> Yeah. I actually use less and less models in the regular way nowadays. >> I use plenty of panels (the app I work on hardly uses separate pages) >> that nest other panels in them (typically detail views or dialogs) >> that reuse models of the parent. But indeed YMMV. >> >> Personally, I think the whole generics business exposes that the >> one-one relation between components and models is flawed. Without >> generics this isn't much of a problem, just the odd unused member and >> constructor, but as generics aren't as 'optional' it is all very in >> your face suddenly. >> >> I think on the longer term (post 1.4) we should re-think how models >> work in Wicket. See if we can find an elegant way to make this more >> flexible (I'm not in favor of the id based thing someone posted >> earlier btw) without breaking the whole world. >> > > We discussed this on ##wicket yesterday. I asked why we have models > on all components and someone pointed out that the main reason was > about the detach stuff I believe. But, couldn't that be solved by > having some components that implement something like IModelDriven (or > IModelBacked or whatever) and the detach logic could apply to only > those components? Also, someone has pointed out that when they create > their own components, they sometimes (such as in Palette) have > multiple "models" that they deal with. Allowing components to name > their models what they want would be nice, too. > >> FWIW, I'm still on the fence when it comes to whether we should go for >> a full or partial (models only) implementation of generics, though I'm >> leaning towards partial. >> >> Eelco >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
