The reason why those were made private was because the API should depend on the actual value of the strings, not the declared constants. It was a mistake to declare them public in the first place,.
It also ends up with duplicate documentation, which is always a bad thing (because if those two ever get out of sync...)
Besides, I figured nobody used them. Looks like was wrong... /Janne On Jul 4, 2008, at 07:40 , Murray Altheim wrote:
I note that all of the PARAM_ member variables in InsertPage plugin have been changed from public to private. For both those extending a plugin or those writing code that accesses the parameters of a plugin marking them as private is a problem. As things are this breaks my IfInsertPage extension, in particular. public static final String PARAM_PAGENAME = "page"; public static final String PARAM_STYLE = "style"; ... are now: private static final String PARAM_PAGENAME = "page"; private static final String PARAM_STYLE = "style"; ... I would actually prefer adding some minimal javadocs to each: /** The <b>pagename</b> parameter, whose value is {$value}. */ public static final String PARAM_PAGENAME = "page"; (or something akin.) Apart from some sense of hiding variables I think we should have a "best practices" policy of exposing the parameters of each plugin unless there is some overriding reason not to (such as security). They are, after all, static final strings that users are expected to be able to type anyway. Any objection to changing things back to the way they were? Murray...................................................................... ..... Murray Altheim <murray07 at altheim.com> === = = http://www.altheim.com/murray/ = = === SGML Grease Monkey, Banjo Player, Wantanabe Zen Monk = = = =Boundless wind and moon - the eye within eyes, Inexhaustible heaven and earth - the light beyond light, The willow dark, the flower bright - ten thousand houses, Knock at any door - there's one who will respond. -- The Blue Cliff Record
