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()...)
-----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]
