For once, I agree - getList() has no need to be public.  It is a ListView, so a 
cast to List of getModelObject() by the user prior to checking is not 
unexpected.  And Java5 generics will eventually do away with that anyway.  
protect it.  But do at least change the JavaDoc, so that an developer 
overriding ListView knows to expect the immutable EMPTY_LIST, and never null.

-S.


________________________________

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Johan Compagner
Sent: 16 September 2005 10:55
To: wicket-user@lists.sourceforge.net
Subject: Re: [Wicket-user] Possible ListView Bug - Found word(s) list error in 
the Text body


i hate checking every where for null first.
getList is more like a internal useage so i am no inclined to make it protected
users should use getModelObject() itself
and use setModelObject() for setting the list (there is for example now 
setList())

And when we go for java 1.5 (wicket 2.0 i think)
then getList could be removed because we could make it generified then.




On 9/16/05, Simon Berriman < [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > 
wrote: 

        Returning a new ArrayList() would be dangerous, as add()ing to it would 
have no effect on the ListView, as it is not in the Model, and, as Johan said, 
asking for the List shouldn't set the Model.  getList() should either return 
null, or stay as it is.  Either of these allows the user to do a test (instead 
of catching an exception) before proceeding.  I don't think 
'getList().add(someObject)' can safely be implemented, and this should be 
documented.  You just have to resign yourself to:
        
        List myList = myListView.getList();
        if (myList != Collections.EMPTY_LIST) mylist.add(someObject);
        /* or, if changed to return 'null' */
        if (myList != null) mylist.add(someObject); 
        
        
        At least returning Collections.EMPTY_LIST allows some tests to work 
directly, such as:
        
        if (myListView.getList().size() > 0) {...}
        
        OTOH, convenience is all well and good, but at least if you return (and 
user tests for test for) 'null', then you always *know* that there is no 
underlying List, whatever List method you want to use.
        
        I reckon returning null would be better.
        -S.












Come visit us at: 

Content Management Europe Exhibition.  29th November - 1st December 2005, 
Olympia Grand Hall, London.  Stand # 341

GOSS - Ranked 4th in the Deloitte Technology Fast 50 Awards 2004 and 88th in 
the Deloitte Technology Fast 500 EMEA. 

This email contains proprietary information, some or all of which may be 
legally privileged. It is for the intended recipient only. If an addressing or 
transmission error has misdirected this email, please notify the author by 
replying to this email. If you are not the intended recipient you may not use, 
disclose, distribute, copy, print or rely on this email. 

 

Email transmission cannot be guaranteed to be secure or error free, as 
information may be intercepted, corrupted, lost, destroyed, arrive late or 
incomplete or contain viruses. This email and any files attached to it have 
been checked with virus detection software before transmission. You should 
nonetheless carry out your own virus check before opening any attachment. GOSS 
Interactive Ltd accepts no liability for any loss or damage that may be caused 
by software viruses.
 



-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. Download
it for free - -and be entered to win a 42" plasma tv or your very own
Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user

Reply via email to