Mailing-List: contact jspwiki-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: jspwiki-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of andrew.jaquith@me.com
 designates 17.148.16.98 as permitted sender)
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Message-id: <2E63CB74-657B-478D-854D-3B09E662C978@me.com>
From: Andrew Jaquith <andrew.jaquith@me.com>
To: jspwiki-dev@incubator.apache.org
In-reply-to: <522B8F3D-ACFF-485E-AC41-289BB9F63AA8@ecyrd.com>
Subject: Re: WikiContext & JCR Sessions
Date: Mon, 25 Aug 2008 18:05:13 -0400
References: <D2674022-A79F-473A-B5D9-5784C1A8EE68@ecyrd.com>
 <308CFC47-1ADB-432C-9984-EC3271D9C33B@me.com>
 <965C2438-A0EC-4068-956A-4C9704D876B6@ecyrd.com>
 <6DD01506-20B7-48FB-BD44-7A432C0D3402@me.com>
 <6F9C5370-FFAB-41BD-A606-2781AC38A530@ecyrd.com>
 <3C27DB21-27C9-427C-A30B-4BCC5CDE9810@me.com>
 <522B8F3D-ACFF-485E-AC41-289BB9F63AA8@ecyrd.com>

> 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