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