ActionBeanContext is really just meant to encapsulate HTTP request
state. (From the Stripes Javadoc: "Encapsulates information about
the current request. Also provides access to the underlying Servlet
API should you need to use it for any reason.") The
ActionBeanContext is just a property of an ActionBean, and it can
be set or get freely.
Rendering might well be one of those concerns that should be
cleanly separated from HTTP. In fact, it probably should be.
However, don't think we should build rendering functions into
WikiContext directly. A property that allows the rendering context
to be obtained, similar to how the HTTP context can be obtained via
getContext(). Maybe getRenderingContext()? Making accessible via a
delegate method is probably a lot cleaner than building it into an
abstract superclass.
What kinds of functionality do you foresee RenderingContext needing?
Well, RenderingContext needs to provide page context information
(i.e. getWikiPage()) for example to determine the real URLs for any
relative links, as well as page variables. So it sounds like it
should be a relative of WikiContext. It should also have pretty
broad access (e.g. to determine variable values from the HttpRequest,
so it might need access to that, too). Also, if any plugins exist on
the page, they *will* need access to the full WikiContext. Also, the
idea would be that someone who only wants the JSPWiki rendering
capability can pass their own RenderingContext to it, so it should be
fairly simple.
Agree on that we don't want to put the rendering stuff into
WikiContext. It would only confuse things. Making it available via
a factory or a delegate method is probably the best idea (with slight
preference to the factory, because then it can be made independent of
other structures).
So, we have...
WikiSession - contains user information and any thread-safe things
which are expensive to create.
WikiActionBeanContext - encapsulates the basic info about the
request. Does not require a WikiPage.
WikiContext - provides access to JSPWiki internals; lives exactly as
long as an WikiActionBeanContext; requires a WikiPage.
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.
...
}
public class WikiActionBeanContext
{
public WikiSession getSession();
public WikiEngine getEngine();
public HttpServletRequest getRequest();
public HttpServletResponse getResponse();
}
public class WikiPageActionBeanContext extends WikiActionBeanContext
implements WikiContext
{
...
}
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
