Break the behavior and correctly implement it. This method was initially done to check for preferences changes in the XWiki.XWikiPreferences page and it has not been used that much. I don't think you will break any existing usages.
Ludovic [EMAIL PROTECTED] wrote: > 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 > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > > -- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
