incubator-jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew R Jaquith <andrew.r.jaqu...@gmail.com>
Subject Re: Summary of votes for Andrew's 3 items
Date Sat, 03 Jan 2009 19:46:41 GMT
> 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...

Mime
View raw message