Yes you are right, if we set the variable in the constructor but make it null
on detach, we will not have it on getObject on next render, so we need to
keep a reference to it. I guess the only choice would be to the
LoadableDetachableModel, which could be thought detrimental for code
clearness outweighing the storage impact, maybe would make sense maybe for a
large string - for ex. setting some generated javascript on a label.
But is a page consider stateless if we only have this static string ending
in the page store?
bgooren wrote:
>
> Well, a couple of strings more or less usually don't make that much of a
> difference. I personally prefer to save some typing and have better
> readability then to save a few bytes here and there.
>
> Furthermore, if you were to create an implementation of IModel
> specifically for this case, you would always need to store the string as
> an instance variable, thus creating the "problem" you are trying to solve.
>
>
> Serban Balamaci wrote:
>>
>> Hello.
>> I've always used
>> add(new Label("alabel", new Model("A message")); - does this not save the
>> "A message" string in the page store?
>> Is it not better to do add(new Label("alabel", new
>> LoadableDetachableModel<String>() {
>>
>> @Override
>> protected String load() {
>> return "A message";
>> }
>> })); - while this option does not save it in the page store.
>> Is it because of the coding amount that nobody is using this? I guess not
>> because we could extend IModel and create a "label model" with a string
>> property that is cleared on detach.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
>>
>>
>
>
--
View this message in context:
http://old.nabble.com/Model-to-use-for-static-Label-text-tp27695054p27700379.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
