WikiSession - contains user information and any thread-safe things
which are expensive to create.
Yes.
WikiActionBeanContext - encapsulates the basic info about the
request. Does not require a WikiPage.
Yes.
WikiContext - provides access to JSPWiki internals; lives exactly as
long as an WikiActionBeanContext; requires a WikiPage.
Yes.
RenderingContext - provides access to JSPWiki internals and
rendering parameters; requires a WikiPage; thrown away after a chunk
of wikimarkup is rendered.
// Only bare minimum to make rendering work
public interface RenderingContext
{
public WikiPage getPage();
public WikiEngine getEngine();
...
}
// Extra context
public interface WikiContext extends RenderingContext
{
public HttpServletRequest getRequest(); // This already exists.
...
}
Makes sense. However, see my comments below.
public class WikiActionBeanContext
{
public WikiSession getSession();
public WikiEngine getEngine();
public HttpServletRequest getRequest();
public HttpServletResponse getResponse();
}
Yes.
public class WikiPageActionBeanContext extends WikiActionBeanContext
implements WikiContext
{
...
}
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:
1) Support classes -- used by ActionBeans
ActionBeanContext
--> sets/gets HttpServletRequest
--> sets/gets HttpServletResponse
WikiActionBeanContext
--> extends ActionBeanContext
--> gets/sets WikiEngine
--> gets/sets WikiSession
2) ActionBean classes
ActionBean
--> gets/sets ActionBeanContext
--> gets/sets request parameters submitted by user
WikiActionBean (interface) + AbstractWikiActionBean (abstract class)
--> extends ActionBean
--> sets/gets WikiActionBeanContext
--> contains much of today's WikiContext implementation code:
e.g., get/set variables
WikiContext (abstract class)
--> implements WikiActionBean
--> extends AbstractWikiActionBean
--> gets/sets WikiPage
--> gets/sets HttpRequest (which forwards to WikiActionBeanContext)
ViewActionBean (concrete class)
--> extends WikiContext
--> gets/sets version
--> contains "view" handler method
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.
The re-worked hierarchy would look like this:
1) Support classes -- used by ActionBeans
ActionBeanContext -- same as before
--> sets/gets HttpServletRequest
--> sets/gets HttpServletResponse
WikiActionBeanContext -- changed. (Could also be called WikiContext)
--> extends ActionBeanContext
--> gets/sets WikiEngine
--> gets/sets WikiSession
--> contains much of today's WikiContext implementation code:
e.g., get/set variables
2) ActionBean classes
ActionBean -- same as before
--> gets/sets ActionBeanContext
--> gets/sets request parameters submitted by user
WikiActionBean -- same as before
--> extends ActionBean
--> sets/gets WikiActionBeanContext
ViewActionBean (concrete class) -- changes slightly
--> extends WikiContext
--> gets/sets WikiPage
--> gets/sets version
--> contains "view" handler method
So the basic idea would be that we use the Wiki/RenderingContext as
interfaces announcing what kind of functionalities are required, and
use the ActionBeanContext classes to implement these. Or maybe they
should be ActionBeans, I am not too sure (and I'm too lazy right now
to snap the code out of SVN ;-)
(The rendering code can then check whether it has a full WikiContext
or just a RenderingContext, and then function accordingly.)
/Janne
