you still have ondetach()...but for convinience we can automatically detach any imodel fields, i actually wanted to do this for a while...
-igor On Wed, Jun 4, 2008 at 8:43 AM, Johan Compagner <[EMAIL PROTECTED]> wrote: > and if i store it in metadata ;) > > > On Wed, Jun 4, 2008 at 5:16 PM, Igor Vaynberg <[EMAIL PROTECTED]> > wrote: > >> why even have an interface? just detach all imodel fields via reflection! >> >> -igor >> >> >> On Wed, Jun 4, 2008 at 3:37 AM, 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] >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
