You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Tim Lucia <ti...@yahoo.com> on 2004/01/01 16:49:46 UTC
RE: Problem with action chaining
Ted,
Thanks for the reply.
Putting methods in the base action(s) works (since the actions are
related by what attributes they add to the request or session.) The
down side is that the page designer who is ignorant of Java (or may not
have access to the code) can't make changes this way. If I have an
action to retrieve each business object and put it in the request
(session) under a known key, then the page designer can chain these
together to produce the objects necessary for the view. I hesitate to
say that the actions are "doing actual work", other then the bare
minimum - access the DAO to get a (list of) object(s) and place it
(them) in a request (session) attribute.
(Background note -- I have a requirement where there will be
customizations done by field engineers at various customer sites. They
need to know how to move tiles around (new layouts), and understand
basic struts tag libraries, and HTML [which they already know]. By
chaining actions, they can use the existing .class files without us
shipping the java sources and having them modified in the field.)
Happy New Year,
Tim
> -----Original Message-----
> From: Ted Husted [mailto:husted@apache.org]
> Sent: Wednesday, December 31, 2003 4:10 PM
> To: Struts Users Mailing List
> Subject: RE: Problem with action chaining
>
>
> On Wed, 31 Dec 2003 12:36:33 -0500, Tim Lucia wrote:
> > So is it a bad design if you have
> >
> >
> > Action1 -> add CollectionOfObject1 to request
> > Action2 -> add Object2 request
> >
> >
> > And then chain them together to produce two request attributes? I
> > have some pages which display a list of Object1, and other
> pages which
> > require the Collection to populate a select. So I define
> action path
> > 1 to be action 1 and forward to the display for the Collection of
> > Object1, and define action path 2 to be action 1 forward to
> action 2
> > forward to editor page which has a select of collection of
> object 1,
> > while editing Object2.
>
> One common strategy is to use one action as a "page
> controller" and another as
> the "business transaction controller".
>
> The "business" action works as a go between with the business
> API and DAO
> objects. The Action class extracts any needed input from the
> ActionForm and
> packages for the API/DAO objects. If appropriate, it also
> bundles any output and
> places it in a servlet context, sometimes by populating an
> ActionForm, other
> times by creating some other bean.
>
> The "page" action ensures that whatever assets the page needs
> are available.
> These may be lists for drop-down boxes and so forth. This may
> also mean
> interacting with the API/DAO objects, but the interaction is
> static and driven
> by the page display requirements, rather than what the user input..
>
> As mentioned, each of these actions should represent a single
> "unit of work".
> The business Action is an adapter for the user input. The
> page Action is an
> adapter for the page output.
>
> The core idea is that Actions are Adapters -- not the actual
> working classes.
> When people start chaining several actions together, it is
> usually a signal that
> the Actions classes are doing actual work, rather than just
> acting as a
> go-between with the business classes.
>
> The problem with Actions doing the work is that these classes
> are bound to
> Struts and to the HttpServlet platform. Struts Actions are
> not easy to reuse
> outside of Struts and are more difficult to test than POJO
> business classes.
>
> Creating your own set of business API or DAO classes isn't
> difficult. You can
> use a PlugIn to create a instance of your classes in
> application scope under a
> known name and then have the Actions call them there. Just be
> sure they are
> thread-safe, like Actions.
>
> Or, depending on your circumstances, Actions can create new
> instances of
> business classes so you don't have to worry about
> thread-safety. Object creates
> are a lot cheaper than they used to be.
>
> If several of the page or business Action classes need to do
> the same thing that
> isn't business-related (create some presentation collection
> or what-not), you
> can put that code in a base Action that any subclass can
> call. In that way, you
> get code-reuse the old-fashioned way, instead of by making
> multiple trips
> through the HTTP layer.
>
> HTH, Ted.
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: Problem with action chaining
Posted by Tim Lucia <ti...@yahoo.com>.
Ted,
I'm not sure how scripting will help. The page designers (or
customizers in some cases) will have to know some scripting language,
and someone (probably me) will have to support some additional
mechanisms for the scripts to do the DAO work (design, develop, test,
...)
I dug out your book, and carefully read section 8.4 "Chaining Actions".
It says basically what you've said in this thread (good thing, eh? ;-) )
and in general I agree. However, I still have a case where I think the
chaining is valid, and that comes when using the validator, and the
input parameter points to an Action. Suppose I have a list of objects
in the view, and I click the edit button next to one of them. The
resulting URI becomes something like /EditObject.do?ID=102. The mapping
for /EditObject.do points to com.mycompany.actions.ObjectAction,
parameter="load", and the forward goes to /ObjectEditor.do, which has
validation=true, forwards to a tile, and has input="/ObjectEditor.do".
This way, the initial load of the object to be edited comes from the
DAO, and if validation fails, the validator points back to the editor
page, leaving the "incorrect" input in the form to be corrected, rather
then starting with the DAO value of the data (this way, the error
messages make more sense.)
I think my original posting may have been misleading to a degree. I was
suggesting writing new (additional) ActionMappings to reuse existing
Action classes to create new views.
Thanks again,
Tim
> -----Original Message-----
> From: Ted Husted [mailto:husted@apache.org]
> Sent: Thursday, January 01, 2004 2:35 PM
> To: Struts Users Mailing List
> Subject: RE: Problem with action chaining
>
>
> In your case, something to consider might be to use BSF
> scripts instead of Java Actions.
>
> <http://struts.sourceforge.net/struts-bsf/index.html>
>
> Another idea would be to reduce the business classes to
> Commands (using the Command Chain of Command package)
> <http://jakarta.apache.org/commons/sandbox/chain/>. A
> standard Action could then be used to run one or more
> business Commands.
>
> Something else that has been mentioned is the idea of using
> JSPs for Actions, but I don't know that anyone has
> implemented anything yet.
>
> -Ted.
>
>
> On Thu, 01 Jan 2004 10:49:46 -0500, Tim Lucia wrote:
> > Ted,
> >
> >
> > Thanks for the reply.
> >
> >
> > Putting methods in the base action(s) works (since the actions are
> > related by what attributes they add to the request or session.) The
> > down side is that the page designer who is ignorant of Java (or may
> > not have access to the code) can't make changes this way.
> If I have an
> > action to retrieve each business object and put it in the request
> > (session) under a known key, then the page designer can chain these
> > together to produce the objects necessary for the view. I
> hesitate to
> > say that the actions are "doing actual work", other then the bare
> > minimum - access the DAO to get a (list of) object(s) and place it
> > (them) in a request (session) attribute.
> >
> > (Background note -- I have a requirement where there will be
> > customizations done by field engineers at various customer
> sites. They
> > need to know how to move tiles around (new layouts), and understand
> > basic struts tag libraries, and HTML [which they already know]. By
> > chaining actions, they can use the existing .class files without us
> > shipping the java sources and having them modified in the field.)
> >
> > Happy New Year,
> > Tim
> >
> >
> >> -----Original Message-----
> >> From: Ted Husted [mailto:husted@apache.org]
> >> Sent: Wednesday, December 31, 2003 4:10 PM
> >> To: Struts Users Mailing List
> >> Subject: RE: Problem with action chaining
> >>
> >>
> >> On Wed, 31 Dec 2003 12:36:33 -0500, Tim Lucia wrote:
> >>
> >>> So is it a bad design if you have
> >>>
> >>>
> >>> Action1 -> add CollectionOfObject1 to request
> >>> Action2 -> add Object2 request
> >>>
> >>>
> >>> And then chain them together to produce two request
> attributes? I
> >>> have some pages which display a list of Object1, and other
> >>>
> >> pages which
> >>> require the Collection to populate a select. So I define
> >>>
> >> action path
> >>> 1 to be action 1 and forward to the display for the Collection of
> >>> Object1, and define action path 2 to be action 1 forward to
> >>>
> >> action 2
> >>> forward to editor page which has a select of collection of
> >>>
> >> object 1,
> >>> while editing Object2.
> >>>
> >>
> >> One common strategy is to use one action as a "page
> controller" and
> >> another as the "business transaction controller".
> >>
> >> The "business" action works as a go between with the
> business API and
> >> DAO objects. The Action class extracts any needed input from the
> >> ActionForm and
> >> packages for the API/DAO objects. If appropriate, it also bundles
> >> any output and
> >> places it in a servlet context, sometimes by populating an
> >> ActionForm, other times by creating some other bean.
> >>
> >> The "page" action ensures that whatever assets the page needs are
> >> available. These may be lists for drop-down boxes and so
> forth. This
> >> may also mean
> >> interacting with the API/DAO objects, but the interaction is
> >> static and driven
> >> by the page display requirements, rather than what the user
> >> input..
> >>
> >>
> >> As mentioned, each of these actions should represent a
> single "unit
> >> of work". The business Action is an adapter for the user
> input. The
> >> page Action is an adapter for the page output.
> >>
> >> The core idea is that Actions are Adapters -- not the
> actual working
> >> classes. When people start chaining several actions together, it is
> >> usually a signal that
> >> the Actions classes are doing actual work, rather than just
> >> acting as a go-between with the business classes.
> >>
> >> The problem with Actions doing the work is that these classes are
> >> bound to Struts and to the HttpServlet platform. Struts
> Actions are
> >> not easy to reuse
> >> outside of Struts and are more difficult to test than POJO
> >> business classes.
> >>
> >> Creating your own set of business API or DAO classes isn't
> difficult.
> >> You can use a PlugIn to create a instance of your classes in
> >> application scope under a
> >> known name and then have the Actions call them there. Just be
> >> sure they are thread-safe, like Actions.
> >>
> >> Or, depending on your circumstances, Actions can create
> new instances
> >> of business classes so you don't have to worry about thread-safety.
> >> Object creates are a lot cheaper than they used to be.
> >>
> >> If several of the page or business Action classes need to
> do the same
> >> thing that isn't business-related (create some presentation
> >> collection or what-not), you
> >> can put that code in a base Action that any subclass can call. In
> >> that way, you
> >> get code-reuse the old-fashioned way, instead of by making
> >> multiple trips through the HTTP layer.
> >>
> >> HTH, Ted.
> >>
> >>
> >> ------------------------------------------------------------------
> >> --- To unsubscribe, e-mail: struts-user-
> >> unsubscribe@jakarta.apache.org For additional commands, e-mail:
> >> struts-user-help@jakarta.apache.org
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: struts-user-
> unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: Problem with action chaining
Posted by Ted Husted <hu...@apache.org>.
In your case, something to consider might be to use BSF scripts instead of Java Actions.
<http://struts.sourceforge.net/struts-bsf/index.html>
Another idea would be to reduce the business classes to Commands (using the Command Chain of Command package) <http://jakarta.apache.org/commons/sandbox/chain/>. A standard Action could then be used to run one or more business Commands.
Something else that has been mentioned is the idea of using JSPs for Actions, but I don't know that anyone has implemented anything yet.
-Ted.
On Thu, 01 Jan 2004 10:49:46 -0500, Tim Lucia wrote:
> Ted,
>
>
> Thanks for the reply.
>
>
> Putting methods in the base action(s) works (since the actions are
> related by what attributes they add to the request or session.)
> The down side is that the page designer who is ignorant of Java (or
> may not have access to the code) can't make changes this way. If I
> have an action to retrieve each business object and put it in the
> request (session) under a known key, then the page designer can
> chain these together to produce the objects necessary for the view.
> I hesitate to say that the actions are "doing actual work", other
> then the bare minimum - access the DAO to get a (list of) object(s)
> and place it (them) in a request (session) attribute.
>
> (Background note -- I have a requirement where there will be
> customizations done by field engineers at various customer sites.
> They need to know how to move tiles around (new layouts), and
> understand basic struts tag libraries, and HTML [which they already
> know]. By chaining actions, they can use the existing .class files
> without us shipping the java sources and having them modified in
> the field.)
>
> Happy New Year,
> Tim
>
>
>> -----Original Message-----
>> From: Ted Husted [mailto:husted@apache.org]
>> Sent: Wednesday, December 31, 2003 4:10 PM
>> To: Struts Users Mailing List
>> Subject: RE: Problem with action chaining
>>
>>
>> On Wed, 31 Dec 2003 12:36:33 -0500, Tim Lucia wrote:
>>
>>> So is it a bad design if you have
>>>
>>>
>>> Action1 -> add CollectionOfObject1 to request
>>> Action2 -> add Object2 request
>>>
>>>
>>> And then chain them together to produce two request attributes?
>>> I have some pages which display a list of Object1, and other
>>>
>> pages which
>>> require the Collection to populate a select. So I define
>>>
>> action path
>>> 1 to be action 1 and forward to the display for the Collection
>>> of Object1, and define action path 2 to be action 1 forward to
>>>
>> action 2
>>> forward to editor page which has a select of collection of
>>>
>> object 1,
>>> while editing Object2.
>>>
>>
>> One common strategy is to use one action as a "page controller"
>> and another as the "business transaction controller".
>>
>> The "business" action works as a go between with the business API
>> and DAO
>> objects. The Action class extracts any needed input from the
>> ActionForm and
>> packages for the API/DAO objects. If appropriate, it also bundles
>> any output and
>> places it in a servlet context, sometimes by populating an
>> ActionForm, other times by creating some other bean.
>>
>> The "page" action ensures that whatever assets the page needs are
>> available.
>> These may be lists for drop-down boxes and so forth. This may
>> also mean
>> interacting with the API/DAO objects, but the interaction is
>> static and driven
>> by the page display requirements, rather than what the user
>> input..
>>
>>
>> As mentioned, each of these actions should represent a single
>> "unit of work".
>> The business Action is an adapter for the user input. The page
>> Action is an adapter for the page output.
>>
>> The core idea is that Actions are Adapters -- not the actual
>> working classes.
>> When people start chaining several actions together, it is
>> usually a signal that
>> the Actions classes are doing actual work, rather than just
>> acting as a go-between with the business classes.
>>
>> The problem with Actions doing the work is that these classes are
>> bound to
>> Struts and to the HttpServlet platform. Struts Actions are not
>> easy to reuse
>> outside of Struts and are more difficult to test than POJO
>> business classes.
>>
>> Creating your own set of business API or DAO classes isn't
>> difficult. You can
>> use a PlugIn to create a instance of your classes in application
>> scope under a
>> known name and then have the Actions call them there. Just be
>> sure they are thread-safe, like Actions.
>>
>> Or, depending on your circumstances, Actions can create new
>> instances of
>> business classes so you don't have to worry about thread-safety.
>> Object creates are a lot cheaper than they used to be.
>>
>> If several of the page or business Action classes need to do the
>> same thing that
>> isn't business-related (create some presentation collection or
>> what-not), you
>> can put that code in a base Action that any subclass can call. In
>> that way, you
>> get code-reuse the old-fashioned way, instead of by making
>> multiple trips through the HTTP layer.
>>
>> HTH, Ted.
>>
>>
>> ------------------------------------------------------------------
>> --- To unsubscribe, e-mail: struts-user-
>> unsubscribe@jakarta.apache.org For additional commands, e-mail:
>> struts-user-help@jakarta.apache.org
>
>
> --------------------------------------------------------------------
> - To unsubscribe, e-mail: struts-user-
> unsubscribe@jakarta.apache.org For additional commands, e-mail:
> struts-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org