2012/8/13 Bertrand Delacretaz <bdelacre...@apache.org>: > On Mon, Aug 13, 2012 at 1:15 PM, Carsten Ziegeler <cziege...@apache.org> > wrote: >> 2012/8/13 Bertrand Delacretaz <bdelacre...@apache.org>: >>> On Mon, Aug 13, 2012 at 11:47 AM, Carsten Ziegeler <cziege...@apache.org> >>> wrote: >>>> ...after fixing these I run into failing integration tests, e.g. >>>> SlingDefaultValuesTest#testDefaultBehaviour posts a new property with >>>> an empty value and checks if the property does not exists afterwards.... >>> >>> IIRC (but that was a long time ago) that's by design. Would we have >>> another way of removing a property via a POST than setting it empty >>> anyways? >>> >> See >> http://sling.apache.org/site/manipulating-content-the-slingpostservlet-servletspost.html >> >> which mentions that @IgnoreBlanks should be used instead > > I don't think IgnoreBlanks can be used to remove properties, IIUC it > just causes request parameters with empty values to be ignored. So IMO > there would be no way to remove a property if we changed the current > behavior.
No, I think it's the other way round! At least looking at the docs and the implementation (though buggy) I get the feeling that without @IgnoreBlanks a blank field is not removing the property but setting it to empty. > >> >> Reading https://issues.apache.org/jira/browse/SLING-1412 where this >> was introduced, it suggests that the current behaviour was not how >> these things have been handled before the fix. > > The first SLING-1412 commit is svn revision 916419, and the > SlingDefaultValuesTest#testDefaultBehaviour test hasn't changed since > rev 656302, so I think the "remove property on empty value" behavior > has been there from rev 656302 or even earlier. Yes, I have the same feeling, but then why has SLING-1412 filed? :) > > IMO the current code is fine, we might just need to update the > @IgnoreBlanks doc (or better: add integration tests for that, and yes > I volunteer ;-) No, the current code only implements some strange behaviour for @IgnoreBlanks which in one way or the other has to be fixed. Regards Carsten > > -Bertrand -- Carsten Ziegeler cziege...@apache.org
