The defaults you can specify are only a fallback that gets returned if
nothing else is available. Thus the getValue call will never return null
if you don't specify null as def. This was intended to save you the
checks on if (value == null) ...
BTW, I stole the javadoc text from JDK preferences which are thus also
underspecified in that manner.
We can clarify this in the next portlet version.
Stefan
Patrick Huber wrote:
I just read the Portlet Preferences part in the Spec and it says
nothing about the detailed behaviour. So I thinks it's save to assume
we're good, when the TCK tests run successfully. So the testsuite may
be too sensitive. And in the end, passing the TCK is everything that
counts...
I also find your summary reasonable.
2006/2/18, Zhong ZHENG <[EMAIL PROTECTED]>:
Thanks Patrick.
Let's resume:
1/ PortletPreferences.getValue(String key, String def)...
If a null string is retrieved for the key, the default value will be
returned.
Having no values bound to the key and having a value which equals
null make no difference.
2/ PortletPreferences.getValues(String key, String[] def)...
If a null array is retrieved for the key, the default array will be
returned.
Empty array and array containing null value(s) are valid arrays, thus
should be returned instead of the default array.
3/ portlet.xml...
<preference> element containing no <value> elements should be treated
as a preference with a null value bound to it.
Given the three rules above, some assertions in pluto-testsuite are wrong.
But the portlet TCK has no problem with that.
So, that's the deal.
Regards.
--
ZHENG Zhong
- http://heavyz.blogspot.com/
- http://people.apache.org/~zheng/
--
"I love deadlines. I like the whooshing sound they make as they fly
by." -- Douglas Adams
