On 2012/05/25 17:58:21, skybrian wrote:
In getEditors: "The returned
list will be live until the next call to setValue() and shouldn't be
used after that."
[...]
Yeah, #3 is out. Option #2 would make sense if we expected that
complaining early means that most people would fix the problem before
it reaches production. I'm not convinced of that; I think people won't
test the corner cases that result in null list fields in their
AutoBeans (particularly if those corner cases come from the server).
AFAICT, that's already an issue with other editors though: in the
DevGuide for editors [1], if the "address" or "manager" is null, then
you'll have an NPE at runtime.
(note: not necessarily AutoBeans, any POJO can be edited with the Editor
framework ;-) )
[1]
https://developers.google.com/web-toolkit/doc/latest/DevGuideUiEditors#Quickstart
So I think #1 might actually be right; accept that the list might be
null and don't break, but don't let the user edit the field either.
Also, I see that having a null is actually the initial state of the
ListEditor so it seems okay to go back to that state.
It seems okay for getEditors to return an empty list when we have no
backing list ("yes, we have no editors").
If that seems okay, here's the javadoc to fix so we don't have to have
this discussion again:
- ListEditor constructor: "The ListEditor will have no backing list
until setValue() is called with a non-null value."
- setValue(): "If a null is passed in, the ListEditor will have no
backing list and edits cannot be made."
- getEditors(): "If there is no backing list, an empty list will be
returned."
- getList(): "Returns null if there is no backing list and edits
cannot be made."
Done.
https://gwt-code-reviews.appspot.com/1664803/
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
