Note that according to Apache rules, in any code change votes a
binding -1 constitutes a veto. So, this one does not pass.
Ok. Assuming your previous comment about re-wording this proposal
still stands, I'll re-draft the question and re-submit.
Craig's point of proper subclassing is a good one and needs to be
taken into account. It might make sense to look whether we can
create good abstract subclasses for certain objects (for example,
WikiPage actually comes to mind as a good candidate for an abstract
base class, since it's mostly an accessor class). WikiContext is
something which probably works well as an interface, but WikiEngine
might also be a good base class.
Agreed. Classes that are "big" today, but could be implemented in
several ways, should have decent abstract base classes. WikiPage would
be a good one. WikiEngine probably also deserves an abstract base
class. WikiSession? Probably that too. The proposed interfaces in the
(just-voted-down) .api package are pretty good starts, though we will
want to claw back the number of methods in some of them. WikiPlugin/
WikiRenderer? I have no opinion on these.
What I am really aiming is that someone who embeds JSPWiki does not
have to start a WikiEngine to get the benefit of JSPWiki rendering
engine (there is an open issue for this), but simply provide their
own implementations for certain classes (and not low-level ones like
Providers, which is the case right now). This means that we need to
have either sane default implementations or possibly interfaces for
WikiEngine, WikiPage and WikiContext (and redesign some things for
PluginManager and VariableManager).
<musing>
Makes sense, although one of the implications of cutting out
WikiEngine from embedding scenarios is that WikiEngine needs to get a
lot dumber. WikiEngine would be more of a configuration-holder where
you can find references to things (like a page renderer), and less of
an all-singing, all-dancing class with convenience methods for
everything.
I tend to lean towards the approach of having an interface, plus:
a) an abstract base class + default implementation, OR:
b) a default implementation that is clearly meant to be extended
Factories are often useful for creating objects. I did one for
WikiContext ("WikiContextFactory"); arguably the PageManager, for
example, is or could be a factory class also. Today's WikiEngine
serves that role, too -- partly.
One thing we haven't looked at is a generic object-factory e.g.:
public interface WikiObjectFactory<T>
T create(Class<? extends T> targetType, Object... args);
</musing>
However, this needs a lot more thinking, and we can't just do it
without proper discussion on this subject.
I'm all for it...
