jspwiki-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Janne Jalkanen <Janne.Jalka...@ecyrd.com>
Subject Re: WikiContext & JCR Sessions
Date Mon, 25 Aug 2008 19:56:45 GMT
> 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.)


View raw message