no getModel() should always just work. It should return the model of the
component
also when it is inherrited and an inherrited will not be initialized in the
constructor..
and the constructor of what? the component itself?? that can't be done
because the parent
is not know at that time (that was 2.0). So it will always be lazy.
they will be constructed a the first call to getModel() and will be cleared
again in detach....So with the next request it will again be done lazy..
So the only solution is that we had an protected IModel getInternalModel()
that just returns the field. so getModel() would be then:
public IModel getModel()
{
IModel tmpModel = getInternalModel();
if (tmpModel == null)
{
this.model = initModel();
tmpModel = this.model;
}
return tmpModel;
}
On 4/26/07, Jan Vermeulen <[EMAIL PROTECTED]> wrote:
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.
