Ok, that's when the model I return in getModel() would not be the one stored in the model member variable. I admit it's risky to allow to overwrite getModel(), if you're accessing the member variable directly is some core methods like initModel() or detach().
But than the question might be: why not always call getModel() ? I would have left out initModel() in the core implementation of getModel(), so that it just returns the member variable. In case of an inherited model, it will get initialized anyway in the constructor or in setModel(). If the user, for some strange reason, want the init to be done lazy, they still can overwrite the basic getModel() implementation for that. And of course, the user is then responsible for what he puts in the getModel(). Why do I insist so much in this ? Because I think that in a component-based framework like Wicket, the relation between specialized components and their corresponding model is essential, and it would be a pity that when creating a specialized component like a table, I cannot let it return directly the tableModel that it uses: IModel is too basic. Jan. Johan Compagner wrote: > > no but if you override getModel() then the model property will never be > set! > So for example if you override getModel() and there you return a > IComponentInhertiable model > or something like that then we will never find that. Because we don't call > getModel() any more > (that in your case would return a model for that component) but we would > look at the model field > that in your case again will never be set. > > There are more places where we now directly look at the model for example > detachModel() > that doesn't do getModel() it again looks directly to the model variable > So if you would override getModel() your model will never be detached. > > johan > > > On 4/26/07, Jan Vermeulen <[EMAIL PROTECTED]> wrote: >> >> >> >> Johan Compagner wrote: >> > >> > ahh and that is the change why getModel() needs to be final now... >> > because here and there we are directly looking at the model field >> instead >> > of >> > calling getModel() >> > so if you would override getModel() all that code would fail (or always >> > see >> > a null value) >> > >> > johan >> > >> >> Sorry, I don't get that. If you don't call getModel(), how can an >> overwritten version break your code ? It would if you were calling >> getModel(), but that's just what it no longer does ! >> >> Jan. >> -- >> View this message in context: >> http://www.nabble.com/Timeframe-to-move-wicket---wicket-ext-projects-to-JDK1.5-tf3638110.html#a10197572 >> Sent from the Wicket - Dev mailing list archive at Nabble.com. >> >> > > -- View this message in context: http://www.nabble.com/Timeframe-to-move-wicket---wicket-ext-projects-to-JDK1.5-tf3638110.html#a10198777 Sent from the Wicket - Dev mailing list archive at Nabble.com.
