On Tue, 12 Aug 2003, Mainguy, Mike wrote:
> Date: Tue, 12 Aug 2003 10:05:15 -0400
> From: "Mainguy, Mike" <[EMAIL PROTECTED]>
> Reply-To: Struts Developers List <[EMAIL PROTECTED]>
> To: 'Struts Developers List' <[EMAIL PROTECTED]>
> Subject: RE: ActionForwards, et al (was SuccessAction)
>
> I think that is reasonable, but, if it is too generic, we would end up with
> no value. I.E. if all we can do it pull generic objects in and out and cast
> them to what they need to be, we end up unifying the interface for a bunch
> of differing technologies, but causing more work when using them by them
> selves.
>
> What would be really cool is if a commons/context framework where developed
> that was based on a Base that had prerolled subclasses that where
> overloaded to return the proper type for what you want (i.e.
> HttpServletRequest, Cookies[], Cookie, Beans, DynaBeans, Maps...) so if you
> are coding an action class, you can get a cookie out of the context by using
> context.getCookie("foo") instead of the more generic (but flexible)
> (Cookie)context.get("foo").
>
> I think an underlying interface would be ok, but, it seems a lot of
> functionality for these different contexts would end up being replicated
> anyway and perhaps we could unify it a bit by putting some core
> functionality in the Base Class (i.e. BeanUtils.copyProperties()...)
>
What you described is pretty much exactly how the Context in commons-chain
is implemented -- but with an extra twist. In order to keep users of the
Context from always having to cast to some known implementation class, it
supports attribute-property transparency. In other words, if your Context
implementation class has a "foo" property that is a String, the following
two calls are identical:
String foo = ((MyContext) context).getFoo();
String foo = (String) context.getAttributes().get("foo");
In addition, commons-chain provides a couple of layers of Context
implementation (optional, compiled only if you have the corresponding
APIs) for web applications:
// The fundamental interface
package org.apache.commons.chain;
public interface Context;
// Convenience base class that does the transparency trick
package org.apache.commons.chain.impl;
public class ContextBase implements Context;
// Abstract base class for web tier Context implementations
package org.apache.commons.chain.web;
public abstract class WebContext extends ContextBase;
// Concrete class for Servlet API
package org.apache.commons.chain.web.servlet;
public class ServletWebContext extends WebContext;
// Concrete class for Portlet API
package org.apache.commons.chain.web.portlet;
public class PortletWebContext extends WebContext;
The WebContext class adds things like the "applicatonScope" property that
returns a Map of the application attributes, whereas ServletWebContext
implements that based on ServletContext, and PortletWebContext implements
that based on PortletContext. Now, someone who receives a Context can be
as generic or specific as they want, and cast only if they want the type
safe property accessors:
Map map = (Map) context.getAttributes().get("applicationScope");
Map map = ((WebContext) context).getAppicationScope();
Note that the latter call works in either a Servlet or a Portlet
environment, because the difference is abstracted away. (JavaServer Faces
does exactly this sort of thing in ExternalContext :-).
And, all of this is a long-winded way of saying that a Context
implementation without some sort of specific functionality isn't really
needed. If what you want is a reusable container for named variables,
we've already got a perfectly good API for that purpose, complete with
very powerful abstractions and a variety of implementations:
java.util.Map
:-).
Craig
>
> -----Original Message-----
> From: Ted Husted [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, August 12, 2003 9:47 AM
> To: Struts Developers List
> Subject: Re: ActionForwards, et al (was SuccessAction)
>
> David Graham wrote:
> > No, I was thinking Actions would be passed an ActionContext in their
> > execute() method similar to how Servlets know about a ServletContext. The
> > ActionContext would contain the HttpServletRequest, form bean, etc. and
> > would serve to keep the API stable while allowing flexibility in what the
> > ActionContext actually contained.
>
> Perhaps it's time for a Commons Context foundation class. Tiles uses a
> Context, Velocity uses a Context, the Commons-Chain sandbox package uses
> a Context, Struts wants to use a Context, and I'm sure that there are
> others.
>
> Ideally, we might want to be able to pass a Context between Struts and
> the business layer as well as other packages like Tiles and Velocity. So
> it might be helpful if they could be implementations of the same
> underlying interface.
>
> Perhaps we could squeeze it into Resources, since, in practice, messages
> are definitely something you would be attaching to a Context.
>
> =:0) I just don't want Geir coming along in a few months and pointing
> out how many Context implementations we have in Jakarta now =:0)
>
> -Ted.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> This message and its contents (to include attachments) are the property of Kmart
> Corporation (Kmart) and may contain confidential and proprietary information. You
> are hereby notified that any disclosure, copying, or distribution of this message,
> or the taking of any action based on information contained herein is strictly
> prohibited. Unauthorized use of information contained herein may subject you to
> civil and criminal prosecution and penalties. If you are not the intended recipient,
> you should delete this message immediately.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
