You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@struts.apache.org by Joe Germuska <Jo...@Germuska.com> on 2004/12/01 00:15:51 UTC

Re: Spring dreaming (was Second call: add "generic" mapped property to ActionConfig)

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

-- 
Joe Germuska            
Joe@Germuska.com  
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction"  -The Ex

Re: Second call: add "generic" mapped property to ActionConfig

Posted by Joe Germuska <Jo...@Germuska.com>.

Yes, I like this better.  Then, a method on ActionConfig:

public String getProperty(String key)

which returns the value which was set.

As an implementation detail, there would also be a setProperty(String 
key, String value).  This method would obey the "configured/frozen" 
semantics of other properties of ActionConfigs, so that users don't 
mistakenly change values during runtime on a shared object.

I think I like Martin's proposed configuration syntax also.  I 
suppose it could be confusing in some ways, but I think those who 
need to use it would figure it out.

I'll probably do this in the next few days.  Thanks for the opinions...

Joe

At 8:30 PM -0800 11/30/04, Martin Cooper wrote:
>I like the idea of having a mapped property like this, but I'm not
>sold on this particular mechanism for implementing it. The reason is
>that it takes the general purpose <set-property> element and makes a
>particular property name "special". That doesn't seem very clean to
>me, and we could end up breaking apps where people are already using a
>'props' property.
>
>I'd prefer to use a new element nested within the action element for
>this, or perhaps even better, enhance the existing <set-property>
>element to handle it. The latter would allow the same mechanism to use
>used anywhere we currently allow <set-property> to be used.
>
>One example of how we might do this:
>
>Do things the way we do now (i.e. a custom property):
><set-property property="foo" value="bar"/>
>
>Set a mapped property instead of an individual one:
><set-property key="foo" value="bar"/>
>
>Notice the use of 'key' instead of 'property' to indicate that this
>will land up as a key/value pair in the mapped property set.

-- 
Joe Germuska            
Joe@Germuska.com  
http://blog.germuska.com
"Narrow minds are weapons made for mass destruction"  -The Ex

Re: Second call: add "generic" mapped property to ActionConfig

Posted by Martin Cooper <mf...@gmail.com>.

I like the idea of having a mapped property like this, but I'm not
sold on this particular mechanism for implementing it. The reason is
that it takes the general purpose <set-property> element and makes a
particular property name "special". That doesn't seem very clean to
me, and we could end up breaking apps where people are already using a
'props' property.

I'd prefer to use a new element nested within the action element for
this, or perhaps even better, enhance the existing <set-property>
element to handle it. The latter would allow the same mechanism to use
used anywhere we currently allow <set-property> to be used.

One example of how we might do this:

Do things the way we do now (i.e. a custom property):
<set-property property="foo" value="bar"/>

Set a mapped property instead of an individual one:
<set-property key="foo" value="bar"/>

Notice the use of 'key' instead of 'property' to indicate that this
will land up as a key/value pair in the mapped property set.

--
Martin Cooper

On Tue, 30 Nov 2004 16:05:16 -0800, Don Brown <mr...@twdata.org> wrote:
> Sure, works for me :)
> 
> Don
> 
> Joe Germuska wrote:
> 
> > <snip />
> >
> > 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: Second call: add "generic" mapped property to ActionConfig

Posted by Don Brown <mr...@twdata.org>.

Sure, works for me :)

Don

Joe Germuska wrote:

> <snip />
>
> 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

Struts API Bean (was Spring dreaming)

Posted by Don Brown <mr...@twdata.org>.

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