i thought not reachable means they are not in any default model slot...dunno
-igor On Wed, May 6, 2009 at 1:17 PM, Johan Compagner <jcompag...@gmail.com> wrote: > Doesnt he say that the models arew really not reachable by the > components? So how would that field scanning then work? If it are > fields on components the currently the thing to do is simpel just make > sure that those fields are detached in the detach method of the > component that has those fields > > On 06/05/2009, Jeremy Thomerson <jer...@wickettraining.com> wrote: >> In 1.5 Igor is planning on doing this. He's planning on making it >> such that any IModel that your component holds as a field is >> auto-detached. >> >> -- >> Jeremy Thomerson >> http://www.wickettraining.com >> >> >> >> >> 2009/5/6 Uwe Schäfer <schae...@thomas-daily.de>: >>> hi >>> >>> we have a problem here, which we think might be a common one, so i´d like >>> to >>> discuss. >>> >>> from time to time we create models (mostly LDMs) that are not actually >>> reachable by components. (yes, you can argue that this is stupid, but it >>> happens where 1:1 mapping between component and model is not easy to >>> apply) >>> >>> the problem arising from there is of course that wicket does not know >>> about >>> this IModel and so wont detach() it. >>> >>> yes, we could use Component.detach() as a hook to detach that LDM as well, >>> but i tend to forget that. >>> >>> if there were a central place to register IDetachables, life would be >>> simpler. from what i´ve seen, detach is not guaranteed to be called only >>> once, so we could do: >>> >>> MyAbstractReadOnlyModel(){ >>> MyRequestCycle.get().registerForDetachment(this);} >>> >>> and to >>> >>> MyRequestCycle.detach(){ >>> super.detach(); >>> for(IDetachable d : this.setOfRegisteredIDetachables){ >>> d.detach(); >>> } >>> this.registeredIDetachables.clear(); >>> ... >>> >>> as well as >>> >>> MyRequestCycle.registerForDetachment(IDetachable d); >>> >>> wouldn´t it make sense to have something like this in the framework? >>> one drawback is that direct implementations of IModel could not be >>> covered, >>> but still it would be more convenient to just register them somewhere >>> instead of overwriting the detach methods of their containers if we want >>> them detached. >>> >>> any thoughts, apart from the ones that claim this not to be a valid use of >>> IModel? :) >>> >>> cu uwe >>> >>> -- >>> THOMAS DAILY GmbH >>> Adlerstraße 19 >>> 79098 Freiburg >>> Deutschland >>> T + 49 761 3 85 59 410 >>> F + 49 761 3 85 59 550 >>> E lar...@thomas-daily.de >>> www.thomas-daily.de >>> >>> Geschäftsführer/Managing Directors: >>> Wendy Thomas, Susanne Larbig >>> Handelsregister Freiburg i.Br., HRB 3947 >>> >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >>> For additional commands, e-mail: users-h...@wicket.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> For additional commands, e-mail: users-h...@wicket.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
