[xwiki-devs] [proposal] change current behaviour of PropertyChangedRule to implement it correctly

Dear developers, while fixing the PropertyChangedRule class (XWIKI-2293) I found that there is no way I can improve the code without breaking the current behaviour: right now, since the className parameter is ignored, upon adding a PropertyChangedRule with no className, the property change is checked on the object returned by XWikiDocument.getxWikiObject() (which is the first object of the class defined in the document). This behaviour makes no sense in the context of a correctly implemented PropertyChangedRule: there might be more than one object of that type so why check only on the first and not all of them, why use the class defined by this document as default in the first place and not test the specified property on all objects, etc. There are two choices: 1) break current behaviour and correctly implement the PropertyChangedRule 2) keep the current PropertyChangedRule class but deprecate it and add a new notification rule class that would correctly implement the property change rule. I prefer the first one, since we can consider the current behaviour to be buggy and this to be the fix, but the choice depends on actually how much this would impact existing code, how much code relies on the current behaviour to create PropertyChangedRules with unspecified classNames. In the core, the only place where PropertyChangedRule is used is to re-prepare plugins when the plugin preference is changed in XWiki.XWikiPreferences, but there might also be some code in products, xwiki applications, etc. Here's my +1 for 1), but I would like to get some opinions on this from the developers. Also, since the PropertyChangedRule behaviour on unspecified className or propertyName is ambiguous I propose to consider the rule as incompletely specified if one of the two is missing and therefore never send notifications from such a rule (though it wouldn't be consistent with DocObjectChangeRule who is currently checking all objects on null className). Here's my +1 for this one, too. WDYT? Happy coding, Anca