required ActionBean method getContext()). The WikiActionBeanContext
itself contains only four references: for WikiEngine, WikiSession,
HttpServletRequest and HttpServletResponse. That's it -- no other
references to Stripes objects, and no long chains of object
references pulling in lots of heavyweight stuff.
Well, that looks good - except for the HttpServletRequest/Response.
Those are dependent on this all being a HTTP application (which may
not be true if you embed the rendering engine in some app). But on
the other hand, we can of course state that those *can* be null in
certain cases, or substitute dummy values (which in turn make these
again Stripes-dependent).
To avoid NPEs, I take the position that HttpServletRequest/Response
references must always be set when a WikiContext/WikiActionBeans are
created, even if the caller doesn't (or cannot) supply any. In other
words, we create some dummy objects (Stripes MockHttpServletRequest/
Response objects actually). Take a look at
WikiActionBeanFactory.newInstance() in ARJ_STRIPES_BRANCH....
Is this sort of thing a kluge? Yes. Does it make us dependent on
Stripes? No, because there aren't any references made or kept to
Stripes classes other than the ActionBeanContext subclass itself
(WikiActionBeanContext). It's more, as you point out, a dependency on
HTTP.
I'm not worried about HTTP requests, I'm worried about cases
*outside* HTTP (still trying to think separation of rendering and
the rest).
Got it...
What is the real relationship between WikiContext and
WikiActionBeanContext? For rendering, I think we need a separate
RenderingContext interface, which encapsulates everything that the
rendering engine needs into one interface. But I am currently
unsure as to how all these should relate to each other.
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?
Andrew
