On 16.07.2012, at 17:07, Jeremy Booth wrote:
> For our app we do need to
> differentiate between provided empty and not provided.
I can imagine that this makes sense sometimes (albeit I haven't come across
this yet).
> On 16 July 2012 15:42, Carsten Ziegeler <cziege...@apache.org> wrote:
>> the handling of the empty value happens in the Sling Post servlet -
>> afaik this was a decision in the early days of the post servlet to
>> treat an empty value like no value.
Yes, that was always in the code (I remember refactoring that once for the
@Patch feature). It's clearly commented, albeit the initial reasoning seems
lost:
// if no value is present or a single empty string is given,
// just remove the existing property (if any)
removeProperty(parent, prop);
However, the sling post servlet docs say something different:
http://sling.apache.org/site/manipulating-content-the-slingpostservlet-servletspost.html#ManipulatingContent-TheSlingPostServlet%28servlets.post%29-%7B%7B@IgnoreBlanks%7D%7D
The 2nd example in that section:
<form method="POST" action="/content/page/first" enctype="multipart/form-data">
<input type="hidden" name="stringProperty@TypeHint" value="String"/>
<input type="text" name="stringProperty" value=""/>
</form>
This will _not_ result in an empty property, but in no property at all (just
tested it).
Without knowing the original reasoning for "" == null, I would say the sling
post servlet documentation is king and this is a bug :-)
But one needs to be careful here, as there are so many options involved:
single- vs. multi-value properties, @IgnoreBlanks, @DefaultValue = :null,
@DefaultValue = :ignore ... (see also RequestPropertyTest).
Cheers,
Alex
