incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Harry Metske" <>
Subject Re: API changes in InsertPage plugin
Date Wed, 30 Jul 2008 16:34:33 GMT

2008/7/7 Janne Jalkanen <>

> OK, ok... I'll turn them back.  However, I would very much like to have a
> patch for the javadocs.
> /Janne
> On Jul 5, 2008, at 00:29 , Murray Altheim wrote:
>  Craig L Russell wrote:
>>> On Jul 4, 2008, at 1:37 AM, Murray Altheim wrote:
>>>> Janne Jalkanen wrote:
>>>>> The reason why those were made private was because the API should
>>>>> depend on the actual value of the strings, not the declared constants.
>>>>> was a mistake to declare them public in the first place,.
>>>> I don't follow the logic of that at all. If I've got code that
>>>> interacts with those constants (and they are constants), the
>>>> "actual value of the strings" is the constant value, which I
>>>> need access to programmatically.
>>> To me, the reason to have a private String is to declare an
>>> implementation detail. The reason to have a public String is to declare a
>>> common artifact that is part of the contract of the component.
>>>  From this discussion it appears that the value of the String is part of
>>> the interface definition that is shared among multiple classes, and as such,
>>> should be public.
>>> One nice side effect is code completion in code that depends on the
>>> value. You can start to type InsertPage. PARAM_PAGENAME and the IDE will
>>> suggest completions for it.
>> Craig,
>> In my experience it's a very common thing to extend a plugin, to simplify
>> its name or provide an alias (not having seen the aliasing feature of
>> jspwiki_module.xml until a few weeks ago), to provide a copy in another
>> package (so that only one path needs declaration in,
>> to set default values, alter default values, alter behaviour, to disable
>> features, or to use it as a component in a larger functionality.
>> The lessons on declaring things public, protected and private have been
>> reinforced many times while developing plugins -- things I thought were
>> implementation details turned out to be things that an extension needed
>> access to in the end, as a number of plugins I've written have been
>> extended in ways I'd not originally planned.
>> As for code completion, I'm one of those Luddites who still prefer to
>> program in vi and ant, though last week I took part in a multi-day
>> meeting with a vendor, discussing the details of an API. Their lead
>> developer was using Eclipse to navigate through the API and watching
>> the tooltips and popups of methods and class names was a reminder of
>> what I've been missing. I've used MS Visual C++ so I've seen this before,
>> but I'm *almost* convinced that using Eclipse would be more boon than
>> bane. Almost.
>> Murray
>> ...........................................................................
>> Murray Altheim <murray07 at>                           ===  =
>> =
>>                                     = =
>>  ===
>> 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 Cli

met vriendelijke groet,
Harry Metske
Telnr. +31-548-512395
Mobile +31-6-51898081

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message