Well, I think the first thing is to figure out what should be pulled out. I
think we pretty much know what that is. Basically, anything that has "Http"
or "Servlet" in it.
Then the real trick is to figure out what should be put BACK in. Abstract
support for getRemoteUser is a must. I suppose some abstract support for
getParameter should also be there (ActionContext has getParameter already,
which is confusing me). What about sessions? Anything else?
-Pat
----- Original Message -----
From: "Rickard" <ri...@dr...>
To: "Patrick Lightbody" <pli...@ho...>
Cc: "Mike Cannon-Brookes" <mi...@at...>;
<web...@li...>
Sent: Thursday, August 01, 2002 10:43 AM
Subject: Re: [Webwork-user] problem with running ActionSupport based classes
outside of webwork servlet container
> Patrick Lightbody wrote:
> > Well, for one, WebWork needs to completely remove itself from the "web".
> > This is WW-12 and is critical towards this goal. For example,
> > ActionContext.getRequest() returns an HttpSerlvetRequest object. All the
> > servlet stuff needs to be abstracted away and then allow for a pluggable
> > design that gives the developer the opportunity to dictate how
> > getRemoteUser() or getAttriute() or getParameter() behaves.
>
> True. The context stuff needs to be more modular and pluggable. I'm
> currently implementing the Portlet API (JSR168), and there's a bunch of
> stuff there that needs to be made available to the action(if used for
> Portlet implementation). The user is one of those things. But this
> should only be done if the action is actually used as a portlet. So, the
> ActionContext stuff shouldn't be bloated unnecessarily. Not sure how to
> do this best...
>
> /Rickard
>
> --
> Rickard Öberg
> Senselogic
>
|