You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Don Brown <mr...@twdata.org> on 2004/12/01 01:00:49 UTC
Struts API Bean (was Spring dreaming)
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: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts API Bean (was Spring dreaming)
Posted by Levieux Cedric <ce...@europatrust.com>.
+1 for this
----- Original Message -----
From: "Don Brown" <mr...@twdata.org>
To: "Struts Developers List" <de...@struts.apache.org>
Sent: Wednesday, December 01, 2004 1:00 AM
Subject: Struts API Bean (was Spring dreaming)
> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts API Bean (was Spring dreaming)
Posted by Martin Cooper <mf...@gmail.com>.
On Tue, 30 Nov 2004 16:00:49 -0800, Don Brown <mr...@twdata.org> 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).
Well, let's generalise that to references to objects necessary for the
processing of a specific request, and not tie it to actions per se.
;-) But yes, this would be where things like the current module and
the module's resource bundles are stashed, amongst other things as you
suggested.
--
Martin Cooper
> 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: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts API Bean (was Spring dreaming)
Posted by Joe Germuska <Jo...@Germuska.com>.
At 7:18 AM -0800 12/3/04, David Graham wrote:
>I like the one api bean approach because then you don't have to remember
>the names of the objects to lookup in the context. You just remember one
>name and get the rest from that bean.
>
>We don't need a migration path if we do this for 2.0, only for the 1.x
>series. I'm not sure which series you were planning on doing this in
>though?
I think it should definitely be a clear design constraint on anything
2.0, but I'd like to try to do it on 1.x too. I don't think that's
*too* hard, since in most cases, Struts is doing the writing,
especially to the Servlet context. I'm going to keep thinking about
it and talking about it on the dev list, though. To be honest, my
cycles aren't going to be going into a 2.0 revolution too soon; I'm
expecting to stay focused on pushing Struts 1.x forward for a while.
My personal top priority is the chain request processor.
Other near term things I'm thinking about are:
* small changes to take advantage of our agreement on the move to
Servlet 2.3 -- especially nesting exceptions anywhere they are caught
and a JSP or ServletException are thrown. That should make debugging
a bit easier.
* adding the properties to ActionConfig (hopefully this weekend.
I'll do this on 1.3 and not worry about fitting it into the 1.2
branch. I realized the digester rules to achieve the config syntax
Martin proposed will be a bit wonky, but not a stopper)
* providing an ActionForm method which returns ActionMessages from a
validation method so we can push ahead on fully deprecating
ActionErrors. (Also 1.3. I'll mention the strategy in another
thread to help it be seen...)
Joe
--
Joe Germuska
Joe@Germuska.com
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction" -The Ex
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts API Bean (was Spring dreaming)
Posted by David Graham <gr...@yahoo.com>.
--- Ted Husted <hu...@apache.org> wrote:
> The problem is that one developer's litter is another developer's
> treasure :)
>
> Right now, a lot of components are already pointing to the components
> we've scattered about the contexts. If we just move them into our own
> context, then those references would break.
>
> To create a migration path, we'd first have to provide an ViewContext to
> replace direct access to the components, deprecate direct acess, and
> then, in a future release, move the components our own state mechanism.
I like the one api bean approach because then you don't have to remember
the names of the objects to lookup in the context. You just remember one
name and get the rest from that bean.
We don't need a migration path if we do this for 2.0, only for the 1.x
series. I'm not sure which series you were planning on doing this in
though?
David
>
> -Ted.
>
> On Thu, 02 Dec 2004 09:35:47 -0800, Don Brown wrote:
> > 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: dev-
> >>> unsubscribe@struts.apache.org For additional commands, e-mail:
> >>> dev-help@struts.apache.org
> >>
> >>
> >> ------------------------------------------------------------------
> >> --- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
> >> additional commands, e-mail: dev-help@struts.apache.org
> >>
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
> > additional commands, e-mail: dev-help@struts.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
__________________________________
Do you Yahoo!?
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts API Bean (was Spring dreaming)
Posted by Ted Husted <hu...@apache.org>.
The problem is that one developer's litter is another developer's treasure :)
Right now, a lot of components are already pointing to the components we've scattered about the contexts. If we just move them into our own context, then those references would break.
To create a migration path, we'd first have to provide an ViewContext to replace direct access to the components, deprecate direct acess, and then, in a future release, move the components our own state mechanism.
-Ted.
On Thu, 02 Dec 2004 09:35:47 -0800, Don Brown wrote:
> 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: dev-
>>> unsubscribe@struts.apache.org For additional commands, e-mail:
>>> dev-help@struts.apache.org
>>
>>
>> ------------------------------------------------------------------
>> --- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
>> additional commands, e-mail: dev-help@struts.apache.org
>>
>
> --------------------------------------------------------------------
> - To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For
> additional commands, e-mail: dev-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts API Bean (was Spring dreaming)
Posted by Don Brown <mr...@twdata.org>.
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: dev-unsubscribe@struts.apache.org For
>> additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: Struts API Bean (was Spring dreaming)
Posted by Ted Husted <hu...@apache.org>.
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: dev-unsubscribe@struts.apache.org For
> additional commands, e-mail: dev-help@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org