hi Charles
The whole issue is that you don't know how the data (in this case a
String) is to be retrieved. Can it be read only once ? Should it be
refresh on each request cycle ? On each access to the data ? Does it come
from a database ?
Wicket's model allows you to go away from all these considerations : you
just want to be able to get the string. Just let the users of your wicket
component decide how they want to provide the data.
As such, your example is, I think, broken :
> private Label labelTitle;
> public static Label createLabelTitle(String title) {
> return new Label(title,new PropertyModel( ModelClass, title ));
> }
What if someone wants to change this string ? title = "my new title" won't
work there !
Thus, it should be, IMO :
> public static Label createLabelTitle(final IModel<String> titleModel) {
> return new Label(title,titleModel.get());
> }
++
NB : you might be interested by this article
http://blog.jteam.nl/2009/09/16/wicket-dos-and-donts/
>
> Joseph,
>
> Can you explain a little bit what you mean by provide it with attribute
> (IModel<String>) ?
>
> private Label labelTitle;
> public static Label createLabelTitle(String title) {
> return new Label("title",new Model( title ));
> }
>
> --> becomes
>
> private Label labelTitle;
> public static Label createLabelTitle(String title) {
> return new Label(title,new PropertyModel( ModelClass, title ));
> }
>
> Is it right what I create ?
>
>
> Joseph Pachod wrote:
>>
>> cmoulliard wrote:
>>> What I have done to avoid to repeat the creation of the labels is to
>>> define
>>> and use static method
>>>
>>> private Label labelTitle;
>>> public static Label getLabelTitle(String title) {
>>> return new Label("title",new Model( title ));
>>> }
>>>
>> I personally would name this method createLabelTitle(String title) or
>> getNewLabelTitle(String title), for explicitness.
>>
>> Furthermore, I would directly provide it with a "final IModel<String>
>> title" attribute, not to dictate how the data has to be provided
>> (dynamic or not for example).
>>
>> In the end, this method is fine for just a label, but for anything more
>> complex a panel would be the way to go I would say. The main exception
>> here I see right now is the case of pages.
>>
>> For example, if we're speaking of a page title, then I would define it
>> in my base page and make an abstract String getTitle() method in the
>> base page so I'm sure everyone set it up later on. I would do the same
>> if it's a specific kind of structured page, for example an abstract
>> class ContentHoldingPage extend TheBasePage.
>>
>> ++
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>
>>
>
>
> -----
> Charles Moulliard
> SOA Architect
>
> My Blog : http://cmoulliard.blogspot.com/ http://cmoulliard.blogspot.com/
> --
> View this message in context:
> http://www.nabble.com/Is-it-the-best-way-to-code-a-Link-depending-on-a-condition-tp25488603p25530206.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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
