Re: Struts API Bean (was Spring dreaming)

[Don Brown]

I agree with everything you wrote, however, what I was specifically 
talking about was some sort of storage bean that all the global Struts 
components could be stored in, so we don't have all these Struts objects 
littering the servlet context.  Yes, for each request, a ViewContext 
instance would be created, initialized with this storage bean.

Don
Ted Husted wrote:
The public API bean (where the "rubber meets the road") could *not* be stored in application scope, since some of the Struts resources are request and session based. 

The original idea was the ViewContext (fka ConfigHelper) would be created on a per-request basis (like a Velocity tool). The ViewContext might hold references to members in request, session, or application scope, but the ViewContext client doesn't need to know that. All of the tags and tools can then refer to the ViewContext, rather than having to know where all the "bodies are buried". The ViewContext interface could be based on the Velocity tools APIs (http://jakarta.apache.org/velocity/tools/struts/). I worked with these guys initially, and they are very tough about defining what you need, but no more. 

Internally, we might want to define an ActionContext that provides the same utility as the Action class and would also include the properties from the ActionForm. The idea being you could recode an Action class to use an ActionContext just by changing the references. 

Aside from the Action, we might also define a ResourceContext subset that could be shared with the business layer. The ResourceContext would include the messaging methods, so that the business layer could create Commons Resources messages (as part of a Command) and return them to Struts. This is an interface that we might define as part of the Commons Resources project, so that it is not tainted as a Struts import. Of course, the ActionContext would implement ResourceContext, so that we can exchange the same object with the business layer. 

All of these interfaces would implement Commons Chain Context (hence the suffix). 

The ActionContext could be called from an ActionCommand interface, a Chain 
Command-like interface with one method:
    void Execute(ActionContext context)
Support for conventional Actions would stay in place, but as an alternative, a 
class could implement ActionCommand and unbind itself from the HTTP API.
I would suggest we implement these interfaces as "experimental" in 1.3.x, so that we can work with them ourselves for a while. In 1.4.x, we could do things like refactor for Spring, and then finalize the new interfaces in 1.5.x. 

I know I should reduce this to code, but I'm away this week, and trying to keep a few balls in the air until I get back. 

Eventually, we may to put a collection of Controller beans in application 
scope, open per module. This might be a place where a BeanFactory might be 
useful, but I think there are some other issues we need to iron out first. 
(Else start the revolution!)
-Ted.
On Tue, 30 Nov 2004 16:00:49 -0800, Don Brown wrote:
 

On the topic of a Struts API bean, I completely agree.  We should
have one bean, probably actually stored in the servlet context,
which contains references to all the Struts-specific components
like configuration elements and message resources.  Now this, and
the Spring topic, do overlap since this API bean could actually be
a Spring BeanFactory which might be a more flexible approach
actually.
This would be separate from the ActionContext idea which would hold
references to objects necessary for the execution of actions (chain
context, http request/response, all current Action helper methods,
etc).
Ted, in fact, suggested an API bean previously as well, and I
believe has even started sketching out what one might look like.
Don
Joe Germuska wrote:
   

While I'm one who has had good experiences with Spring's
BeanFactory for managing my business objects, maybe we should
focus first on defining what Struts is and what needs to be
configured.  This would allow us to move more flexibly to various
configuration approaches, or conceivably support more than one.
I've been thinking for a while that we should stop storing so
many things directly in the ServletContext and instead, define a
"Struts" object which would hold these things.  I've mentioned
this obliquely a few times and not gotten much response, so maybe
no one else likes the idea.  Or maybe it's been too oblique.
Benefits of something like this would be reducing dependencies on
the Servlet API and providing a better environment for testing.
Is there any interest in this, or is it cracked?  If it's not
cracked, we might also take a longer-term look at abstracting the
session, which seems tedious, but has some of the same issues.
We may never need to truly abstract away the HttpServletRequest,
since the Chain context will have the same lifecycle and serve
about the same purpose.
Now, then:  This whole thread started as a different question and
was motivated by an earlier question.  Assuming that we continue
to use Digester to instantiate and populate ActionConfig objects,
I would like to add a "generic" mapped property to ActionConfig
so that rather than writing trivial and boring subclasses of
ActionConfig, one can simply set properties on it.  I'd make it a
Properties because I'd expect it to have strings, but I would
accept arguments to make it a map instead with the idea that
later other Objects might get in there.  (Ugh, but all that
casting!)  Assuming no one objects in the next day or two, I'll
assume it's ok, and I'll call it "props", just because I would
rather not screw around waiting for another name.
The motivation for this was a perceived flaw in the ChainAction
and chain DispatchAction classes which won't know in which
catalog to look for the command either one is supposed to
execute.  A generic property map would allow the ChainAction to
define the name of the properties it wants for its configuration,
rather than requiring that its ActionConfig implement some
specific interface just to get one more property in.
Joe
     

--------------------------------------------------------------------
- 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]
 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]