Reading this declaration hurts my head. :)
This last declaration suggests that WikiContext ought to be a type
of ActionBeanContext. I recall discussing that WikiContext was
meant to be a superclass (or a marker interface) for page-oriented
ActionBeans, rather than the ActionBeanContext. I.e., the
relationship diagram would look like this:
My preference is strongly towards WikiContext being an interface. We
know already pretty well what is needed in it.
The idea really is that if someone wants to use JSPWiki as a basic
rendering engine, they can provide their own implementations of the
basic interfaces, without having to bring in the entire JSPWiki
WikiEngine and backend and stuff.
However, it is not crazy to suggest that WikiContext could be a
support class (like WikiActionBeanContext) rather than an
ActionBean class itself. WikiContext shares several characteristics
with WikiActionBeanContext: both need to set references to
WikiEngine and WikiSession, and generally need to get at the
request/response objects. That said, get/setWikiPage are better
left in the ActionBean classes. WikiPage is really a property of
the request, and in the HTTP scenario at least, would be bound by
the magical Stripes request binder.
I think that WikiContext.getPage() *is* required, since it is used
practically everywhere, in all our plugins for example. If that
goes, we can pretty much kiss bye-bye to any attempt at making our
3rd party plugins somewhat easily compatible with 3.0...
Also, I would like to keep the name WikiContext.
The backend does not care whether it is a property of the request or
not - but it needs it in order to resolve relative paths and other
things. So I think that really does need to live on the WikiContext...
Perhaps there should be a superinterface of WikiContext (but a
subinterface of ActionBeanContext) which does not have the WikiPage?
That might have some limited use...
I think your second proposal was pretty good already :-)
/Janne
