Re: Action call another action?

[Michael Jouravlev]

Of course an orphaned item will sit for a while in the session. But
does not this work the same in desktop apps too? Even worse, in
pessimistic systems when you start editing you lock the record. Then
you go have your coffee to piss off colleague who needed the same
record ;-)

In my case only one item sits in the session. If it makes user
experience better and my programming easier, let it sit there. The
good thing is that this is only a memory object, a new one, database
was not called yet. And if the user won't store changes, database
never will be called (well, maybe to generate PK, yes, it will). Also,
if you "exit" from item editing to the item list, item is invalidated
and disposed. So, the only chance to leave it hanging is if the user
wanders off while "Edit Item" window is opened.

Also, I create only one instance of a "current item" for create/edit
process (per session), so at most I will have one item in the session.
No biggie. Microsoft uses extensive approach all the time and it pays.
Who remebers that Win95 needed only 4 megs?

Michael.

On 4/25/05, Adam Hardy <[EMAIL PROTECTED]> wrote:
> On 25/04/05 17:03 Michael Jouravlev wrote:
> > On 4/25/05, Ted Husted <[EMAIL PROTECTED]> wrote:
> >
> >>>in my sample CRUD application i have editAction, which displays an
> >>>item in HTML form. It takes item ID as parameter. This action is
> >>>mapped, it can be called directly from a page using link, like
> >>>editAction.do?ID=1234. Another way to call it is to call it from
> >>>createAction, which creates new item, assigns in ID to it, and
> >>>redirects to editItem with ID attached to the URL as query parameter.
> >>>Is this chaining?
> 
> One disadvantage of this approach is that your app will create orphaned
> items whenever a user abandons the create process after hitting the
> create menu option. Your app will create a new item immediately, but the
> user may wander off and go to lunch without actually using it.
> 
> Well, I might. ;)
> 
> Adam

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

Re: Action call another action?

[Adam Hardy]

On 25/04/05 17:03 Michael Jouravlev wrote:
On 4/25/05, Ted Husted <[EMAIL PROTECTED]> wrote:
in my sample CRUD application i have editAction, which displays an
item in HTML form. It takes item ID as parameter. This action is
mapped, it can be called directly from a page using link, like
editAction.do?ID=1234. Another way to call it is to call it from
createAction, which creates new item, assigns in ID to it, and
redirects to editItem with ID attached to the URL as query parameter.
Is this chaining?
One disadvantage of this approach is that your app will create orphaned 
items whenever a user abandons the create process after hitting the 
create menu option. Your app will create a new item immediately, but the 
user may wander off and go to lunch without actually using it.

Well, I might. ;)
Adam
--
struts 1.2 + tomcat 5.0.19 + java 1.4.2
Linux 2.4.20 Debian
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Action call another action?

[Michael Jouravlev]

On 4/25/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
> On the subject of one Action calling another, one option that is often
> overlooked is to simply instantiate another Action yourself and call
> process() on it manually.  I.e., in Action A do:
> 
> Action ab = new ActionB();
> ab.process(m f, r, r);
> 
> The benefit to this is that you don't need to go through the request
> processing chain again, and you can determine whether you want to use the
> forward returned by the called Action (Action B above) or the one
> generated by the Action doing the calling (Action A above).

This does not work for me since redirection is a key part of my
approach to chaining. I do chaining in order to provide more robust
and friendly UI, not because I just want to reuse some business code.

Michael.

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

Re: Action call another action?

[Michael Jouravlev]

On 4/25/05, Ted Husted <[EMAIL PROTECTED]> wrote:
> > in my sample CRUD application i have editAction, which displays an
> > item in HTML form. It takes item ID as parameter. This action is
> > mapped, it can be called directly from a page using link, like
> > editAction.do?ID=1234. Another way to call it is to call it from
> > createAction, which creates new item, assigns in ID to it, and
> > redirects to editItem with ID attached to the URL as query parameter.
> > Is this chaining?
> 
> The question is whether you are
> 
> * going from one to the another because you need to redirect anyway, or

yes 

> * because you don't want to cut-and-paste business logic between the
> Action classes.

and yes... no, this is not entirely correct. It is not that I did not
want to cut-and-paste business logic, I did not want to cut-and-paste
UI logic. Also, because Struts action can have only one associated
form bean, it seemed natural to split one action into input (setup)
action and output action.

The understanding that redirection can provide better user experience
came later. But now I think this is a natural fit, and I develop all
my future Struts apps in the same manner. So far it works.

> If the latter, then the business API is underdeveloped and the
> application is on a slipperly slope.
> 
> The key point is: Could you call the editAction business logic from
> another Action class if need be?

Umm... Not "from". I can call it anytime, before or after other action.

> The main reason that Action Chaining is bad is because it implies
> people are not creating their own business APIs: The Action classes
> are becoming the API rather than an adaptor to the API. 

No, I am not chaining actions to load this, create that, update that
and then output that. I input data in the first action, update the
model (all business create/delete/update stuff happens here), and in
the output action I simply load business object into form bean and
display it.

> Another reason
> is simply because Struts was not designed to support Action Chaining
> and, out of the box, can't distinguish between a new request and a
> "chained" request.

This works for me, since I use redirection and I want actions to be as
independent as possible.

> The danger is allowing the Actions to become the unit of reuse. The
> business facade should be the unit of reuse.

With all due respect ;) I cannot agree with that. I reuse actions as
UI units, not business units.

> The Actions should be an
> adapter between HTTP and your application's API. There should be a
> very clear line where Struts ends and your business logic begins. As
> Steve McConnell would say: Program into Struts, not with Struts.

Right, but then again, I modularize UI units, not Struts wrappers for
my business processes.

> In this case, it should boil down to a method call on a business
> object that takes an ID and returns the value object we want to edit.
> If that is what the heart of the Action does, then the application is
> on the right road.

That what editAction does, because everything was set up before it is
called. The point is, it does not care where the object comes from. If
it is not in the memory yet, editAction loads the object from the
database.

> > This works great and allows to add a level of abstraction, so editItem
> > does not know where the data comes from. This modularized approach
> > allows to create application with high level of reuse.
> 
> As mentioned, the focus should be on the business object that editItem
> calls, not the editItem Action. The business objects should be the
> unit of reuse, and Actions merely adaptors.

As I said, I respectfully disagree. If a particular action does not
depend on exact sequence, in what other actions were called before it
to set things up, then modularizing actions can be safe and efficient.

I myself found my confession, but I would not want others to follow
commandments blindly only because they express Creator's will ;)

Michael.

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

Re: Action call another action?

[Frank W. Zammetti]

On the subject of one Action calling another, one option that is often
overlooked is to simply instantiate another Action yourself and call
process() on it manually.  I.e., in Action A do:

Action ab = new ActionB();
ab.process(m f, r, r);

The benefit to this is that you don't need to go through the request
processing chain again, and you can determine whether you want to use the
forward returned by the called Action (Action B above) or the one
generated by the Action doing the calling (Action A above).

Don't take this as an endorsement of this approach though, merely as an
FYI on another option.  What Ted eloquently says about a proper business
API facade should make this option irrelevent as well as the others.  But
if you have it in your head that you need/want to chain Actions, this is
another way to do it, one with some benefits that might be important to
you.  I've done this myself on occassion to no ill effect (although I
fight myself when I think of doing it now!)

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

On Mon, April 25, 2005 7:09 am, Ted Husted said:
>> in my sample CRUD application i have editAction, which displays an
>> item in HTML form. It takes item ID as parameter. This action is
>> mapped, it can be called directly from a page using link, like
>> editAction.do?ID=1234. Another way to call it is to call it from
>> createAction, which creates new item, assigns in ID to it, and
>> redirects to editItem with ID attached to the URL as query parameter.
>> Is this chaining?
>
> The question is whether you are
>
> * going from one to the another because you need to redirect anyway, or
> * because you don't want to cut-and-paste business logic between the
> Action classes.
>
> If the latter, then the business API is underdeveloped and the
> application is on a slipperly slope.
>
> The key point is: Could you call the editAction business logic from
> another Action class if need be?
>
> The main reason that Action Chaining is bad is because it implies
> people are not creating their own business APIs: The Action classes
> are becoming the API rather than an adaptor to the API. Another reason
> is simply because Struts was not designed to support Action Chaining
> and, out of the box, can't distinguish between a new request and a
> "chained" request.
>
> The danger is allowing the Actions to become the unit of reuse. The
> business facade should be the unit of reuse. The Actions should be an
> adapter between HTTP and your application's API. There should be a
> very clear line where Struts ends and your business logic begins. As
> Steve McConnell would say: Program into Struts, not with Struts.
>
> In this case, it should boil down to a method call on a business
> object that takes an ID and returns the value object we want to edit.
> If that is what the heart of the Action does, then the application is
> on the right road. If the Action goes through several lines of setup
> and teardown code, that you would not want to maintain elsewhere, then
> the application is on the road to ruin :)
>
> If it's a short road, then there may be little or no harm. But, if it
> is a long road, then there will be problems along the way.
>
>> This works great and allows to add a level of abstraction, so editItem
>> does not know where the data comes from. This modularized approach
>> allows to create application with high level of reuse.
>
> As mentioned, the focus should be on the business object that editItem
> calls, not the editItem Action. The business objects should be the
> unit of reuse, and Actions merely adaptors.
>
>
>>
>> Michael.
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
> --
> HTH, Ted.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


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

Re: Action call another action?

[Frank W. Zammetti]

On the subject of one Action calling another, one option that is often
overlooked is to simply instantiate another Action yourself and call
process() on it manually.  I.e., in Action A do:

Action ab = new ActionB();
ab.process(m f, r, r);

The benefit to this is that you don't need to go through the request
processing chain again, and you can determine whether you want to use the
forward returned by the called Action (Action B above) or the one
generated by the Action doing the calling (Action A above).

Don't take this as an endorsement of this approach though, merely as an
FYI on another option.  What Ted eloquently says about a proper business
API facade should make this option irrelevent as well as the others.  But
if you have it in your head that you need/want to chain Actions, this is
another way to do it, one with some benefits that might be important to
you.  I've done this myself on occassion to no ill effect (although I
fight myself when I think of doing it now!)

-- 
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com

On Mon, April 25, 2005 7:09 am, Ted Husted said:
>> in my sample CRUD application i have editAction, which displays an
>> item in HTML form. It takes item ID as parameter. This action is
>> mapped, it can be called directly from a page using link, like
>> editAction.do?ID=1234. Another way to call it is to call it from
>> createAction, which creates new item, assigns in ID to it, and
>> redirects to editItem with ID attached to the URL as query parameter.
>> Is this chaining?
>
> The question is whether you are
>
> * going from one to the another because you need to redirect anyway, or
> * because you don't want to cut-and-paste business logic between the
> Action classes.
>
> If the latter, then the business API is underdeveloped and the
> application is on a slipperly slope.
>
> The key point is: Could you call the editAction business logic from
> another Action class if need be?
>
> The main reason that Action Chaining is bad is because it implies
> people are not creating their own business APIs: The Action classes
> are becoming the API rather than an adaptor to the API. Another reason
> is simply because Struts was not designed to support Action Chaining
> and, out of the box, can't distinguish between a new request and a
> "chained" request.
>
> The danger is allowing the Actions to become the unit of reuse. The
> business facade should be the unit of reuse. The Actions should be an
> adapter between HTTP and your application's API. There should be a
> very clear line where Struts ends and your business logic begins. As
> Steve McConnell would say: Program into Struts, not with Struts.
>
> In this case, it should boil down to a method call on a business
> object that takes an ID and returns the value object we want to edit.
> If that is what the heart of the Action does, then the application is
> on the right road. If the Action goes through several lines of setup
> and teardown code, that you would not want to maintain elsewhere, then
> the application is on the road to ruin :)
>
> If it's a short road, then there may be little or no harm. But, if it
> is a long road, then there will be problems along the way.
>
>> This works great and allows to add a level of abstraction, so editItem
>> does not know where the data comes from. This modularized approach
>> allows to create application with high level of reuse.
>
> As mentioned, the focus should be on the business object that editItem
> calls, not the editItem Action. The business objects should be the
> unit of reuse, and Actions merely adaptors.
>
>
>>
>> Michael.
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
> --
> HTH, Ted.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


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

Re: Action call another action?

[Ted Husted]

> in my sample CRUD application i have editAction, which displays an
> item in HTML form. It takes item ID as parameter. This action is
> mapped, it can be called directly from a page using link, like
> editAction.do?ID=1234. Another way to call it is to call it from
> createAction, which creates new item, assigns in ID to it, and
> redirects to editItem with ID attached to the URL as query parameter.
> Is this chaining?

The question is whether you are 

* going from one to the another because you need to redirect anyway, or 
* because you don't want to cut-and-paste business logic between the
Action classes.

If the latter, then the business API is underdeveloped and the
application is on a slipperly slope.

The key point is: Could you call the editAction business logic from
another Action class if need be?

The main reason that Action Chaining is bad is because it implies
people are not creating their own business APIs: The Action classes
are becoming the API rather than an adaptor to the API. Another reason
is simply because Struts was not designed to support Action Chaining
and, out of the box, can't distinguish between a new request and a
"chained" request.

The danger is allowing the Actions to become the unit of reuse. The
business facade should be the unit of reuse. The Actions should be an
adapter between HTTP and your application's API. There should be a
very clear line where Struts ends and your business logic begins. As
Steve McConnell would say: Program into Struts, not with Struts.

In this case, it should boil down to a method call on a business
object that takes an ID and returns the value object we want to edit.
If that is what the heart of the Action does, then the application is
on the right road. If the Action goes through several lines of setup
and teardown code, that you would not want to maintain elsewhere, then
the application is on the road to ruin :)
 
If it's a short road, then there may be little or no harm. But, if it
is a long road, then there will be problems along the way.

> This works great and allows to add a level of abstraction, so editItem
> does not know where the data comes from. This modularized approach
> allows to create application with high level of reuse.

As mentioned, the focus should be on the business object that editItem
calls, not the editItem Action. The business objects should be the
unit of reuse, and Actions merely adaptors.


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

-- 
HTH, Ted.

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

Re: Action call another action?

[Michael Jouravlev]

> When I speak of Action chaining, I mean to say a scenario where one
> action mapping's suggested forward path is not directly to a response
> generator (a JSP), but in fact to another mapped action (which will
> eventually forward to a response generator). I was advising against this
> (I know the tempation is there -- I have done it myself) because it
> causes all the dozen or so methods in the request processor "chain" to
> be executed again, redundantly in most cases, and also somewhat because
> of the "hidden" nature of the processing (which is also why I have
> avoided some genuine Struts niceties so far, but, let's face it, a
> strength of Struts is indeed declarative programming).

Ted,

in my sample CRUD application i have editAction, which displays an
item in HTML form. It takes item ID as parameter. This action is
mapped, it can be called directly from a page using link, like
editAction.do?ID=1234. Another way to call it is to call it from
createAction, which creates new item, assigns in ID to it, and
redirects to editItem with ID attached to the URL as query parameter.
Is this chaining?

This works great and allows to add a level of abstraction, so editItem
does not know where the data comes from. This modularized approach
allows to create application with high level of reuse.

Michael.

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

Re: Action call another action?

[Erik Weber]

Ted Husted wrote:
On 4/21/05, Erik Weber <[EMAIL PROTECTED]> wrote:
 

That's the way I do it. If your Actions are light, as they should be, it
doesn't add a lot of code. Some redundant code is not a bad thing, it
can make things clearer. If you were to "chain" actions, then you'd be
going through the entire request processor chain again.
   

I'd even go so far as to say that callling a method on a facade from
more than one action is not redundant. Instead, I would say that it's
a good thing and proves that the facade is well factored.
Typically, I recommend that Actions be used as "transaction scripts"
[Fowler, PEAA]. The Action should call one or more methods on a facade
to initiate and complete the business transaction, and then select the
appropriate response. (Which is what I believe Erik and others on this
thread also do.)
 

Yes, that is a good explanation.
Sometimes the response needs to be created by another Action, but this
is not what we meant when we coined the term "Action Chaining". Action
Chaining is using more than one action to complete the business
transction *before* selecting the response.
 

When I speak of Action chaining, I mean to say a scenario where one 
action mapping's suggested forward path is not directly to a response 
generator (a JSP), but in fact to another mapped action (which will 
eventually forward to a response generator). I was advising against this 
(I know the tempation is there -- I have done it myself) because it 
causes all the dozen or so methods in the request processor "chain" to 
be executed again, redundantly in most cases, and also somewhat because 
of the "hidden" nature of the processing (which is also why I have 
avoided some genuine Struts niceties so far, but, let's face it, a 
strength of Struts is indeed declarative programming). I was imagining 
there might be a way, with the new controller, to put the request back 
through the chain but to somehow say, process X, process Y and process Z 
might be omitted, thus avoiding unnecessary processing, while letting 
process A, B, etc., occur again. This was merely a guess, and I could be 
way off, and am probably missing the point entirely as I haven't played 
with the new controller (or any of the Apache CoR stuff) yet.

 

I think that Struts 1.3, with chain of responsibility implementation,
should allow chaining of actions without causing redundant processing,
but I can't say for sure (at least I hope it does).
   

In 1.3, we are using the Commons CoR to code the request processor. As
a result, the Request Processor is easier to customize. For more about
that see
*  http://wiki.apache.org/struts/WhyChain
Developers might also want to use Commons CoR to create their own
business facade. But   the Commons CoR can be used with *any* version
of Struts, or any version of anything for that matter. (Heck, I'm
using a C# port of CoR with .NET.)
With CoR, it's very easy to create transaction scripts by assembling
the scripts (or "chains") from individual commands in a chain. In the
instant example, "save" could be one command and *list* could be
another. The benefit is that the Action would could call the
"Xylophone" chain without knowing that it included "save" and "list 
*and* that you can change what commands are called by the "Xylophone"
chain by editing the catalog XML document.

For more about Commons CoR, see 

*  http://jakarta.apache.org/commons/chain/cookbook.html
Where CoR really shines is in the preparing rich forms that include
multiple drop-downs and such. Each control can be populated by its own
command. If you add or subtract a control to a page, you can edit the
page and edit the catalog, and never touch the Action that calls the
chain.
What I really like is that I don't have to sweat the facade API.
Before CoR, a lot of effort went into desiging the facade objects so
that the individual methods would be easy to find (high cohesion). Now
that the methods are individual commands, there's one less thing to
design. :)
Of course, the best part is that it's very easy to unit test the
individual commands. If we need another drop down, I write a test and
a command, when the test is green, I plug the command into the chain
and add the control to the JSP. That's it.
Over on dev@, the gang is getting ready to roll 1.2.7, which will
hopefully go GA, and then we should be about ready to roll 1.3.0. We
doubt that 1.3.0 will be GA, but we are eager to tap the keg.
 

Thanks for the explanation. I will have to see some examples for it to 
sink in. I have been mainly using 1.1. I was wanting to upgrade, but 
have been waiting for 1.3 because of the major change. I'll be watching 
for the release. Please announce on this list. :)

Erik
 

Erik
   

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

-
To unsubscribe, e-mail: [EMAI

Re: Action call another action?

[Dakota Jack]

You can deduce all you want, Joe, but this is mistaken.  I notice that
according to your logic, I am now Joe.

Joe

On 4/24/05, Joe Germuska <[EMAIL PROTECTED]> wrote:
> At 3:08 PM -0700 4/24/05, Shey Rab Pawo wrote:
> >
> >On 4/24/05, James Mitchell <[EMAIL PROTECTED]> wrote:
> >>  For the record, you are encouraged to ignore all statements made by Micael
> >>  McGrady, Dakota Jack, or Shey Rab Pawo.
> >  These people are actually the same
> >>  person masquerading as alternate identities,
> >
> >
> >You are quite mistaken about this, James.
> 
> Are you saying that James is mistaken in claiming that these three
> identities are used by one person?
> 
> I thought this message from Shey's account by signed by "Jack" was
> kind of strange.
> 
> http://marc.theaimsgroup.com/?l=struts-user&m=110961169006532&w=2
> 
> More clearly, this message to the Server Side is from "Michael
> McGrady", but is signed "Dakota Jack":
> http://theserverside.com/news/thread.tss?thread_id=31509#154946
> 
> I have been puzzling about this, particularly when a few days ago
> messages came from both Jack and Shey within 20 minutes of each other.
> 
> Joe
> 
> --
> Joe Germuska
> [EMAIL PROTECTED]
> http://blog.germuska.com
> "Narrow minds are weapons made for mass destruction"  -The Ex
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-- 
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

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

Re: Action call another action?

[Joe Germuska]

At 3:08 PM -0700 4/24/05, Shey Rab Pawo wrote:

On 4/24/05, James Mitchell <[EMAIL PROTECTED]> wrote:
 For the record, you are encouraged to ignore all statements made by Micael
 McGrady, Dakota Jack, or Shey Rab Pawo.
 These people are actually the same
 person masquerading as alternate identities,

You are quite mistaken about this, James.
Are you saying that James is mistaken in claiming that these three 
identities are used by one person?

I thought this message from Shey's account by signed by "Jack" was 
kind of strange.

http://marc.theaimsgroup.com/?l=struts-user&m=110961169006532&w=2
More clearly, this message to the Server Side is from "Michael 
McGrady", but is signed "Dakota Jack":
http://theserverside.com/news/thread.tss?thread_id=31509#154946

I have been puzzling about this, particularly when a few days ago 
messages came from both Jack and Shey within 20 minutes of each other.

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

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

Re: Action call another action?

[Ted Husted]

On 4/21/05, Erik Weber <[EMAIL PROTECTED]> wrote:
> That's the way I do it. If your Actions are light, as they should be, it
> doesn't add a lot of code. Some redundant code is not a bad thing, it
> can make things clearer. If you were to "chain" actions, then you'd be
> going through the entire request processor chain again.

I'd even go so far as to say that callling a method on a facade from
more than one action is not redundant. Instead, I would say that it's
a good thing and proves that the facade is well factored.

Typically, I recommend that Actions be used as "transaction scripts"
[Fowler, PEAA]. The Action should call one or more methods on a facade
to initiate and complete the business transaction, and then select the
appropriate response. (Which is what I believe Erik and others on this
thread also do.)

Sometimes the response needs to be created by another Action, but this
is not what we meant when we coined the term "Action Chaining". Action
Chaining is using more than one action to complete the business
transction *before* selecting the response.
 
> I think that Struts 1.3, with chain of responsibility implementation,
> should allow chaining of actions without causing redundant processing,
> but I can't say for sure (at least I hope it does).

In 1.3, we are using the Commons CoR to code the request processor. As
a result, the Request Processor is easier to customize. For more about
that see

*  http://wiki.apache.org/struts/WhyChain

Developers might also want to use Commons CoR to create their own
business facade. But   the Commons CoR can be used with *any* version
of Struts, or any version of anything for that matter. (Heck, I'm
using a C# port of CoR with .NET.)

With CoR, it's very easy to create transaction scripts by assembling
the scripts (or "chains") from individual commands in a chain. In the
instant example, "save" could be one command and *list* could be
another. The benefit is that the Action would could call the
"Xylophone" chain without knowing that it included "save" and "list 
*and* that you can change what commands are called by the "Xylophone"
chain by editing the catalog XML document.

For more about Commons CoR, see 

*  http://jakarta.apache.org/commons/chain/cookbook.html

Where CoR really shines is in the preparing rich forms that include
multiple drop-downs and such. Each control can be populated by its own
command. If you add or subtract a control to a page, you can edit the
page and edit the catalog, and never touch the Action that calls the
chain.

What I really like is that I don't have to sweat the facade API.
Before CoR, a lot of effort went into desiging the facade objects so
that the individual methods would be easy to find (high cohesion). Now
that the methods are individual commands, there's one less thing to
design. :)

Of course, the best part is that it's very easy to unit test the
individual commands. If we need another drop down, I write a test and
a command, when the test is green, I plug the command into the chain
and add the control to the JSP. That's it.

Over on dev@, the gang is getting ready to roll 1.2.7, which will
hopefully go GA, and then we should be about ready to roll 1.3.0. We
doubt that 1.3.0 will be GA, but we are eager to tap the keg.

> 
> Erik

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

Re: Action call another action?

[Shey Rab Pawo]

On 4/24/05, James Mitchell <[EMAIL PROTECTED]> wrote:
> For the record, you are encouraged to ignore all statements made by Micael
> McGrady, Dakota Jack, or Shey Rab Pawo. 
 These people are actually the same
> person masquerading as alternate identities, 


You are quite mistaken about this, James.  I am not sure what upset
you about my statements about CoR.  I also have no idea why you think
what I said was "outmoded" or at all offensive.




 
> I may be mistaken but I think that the CoR (Chain of Responsibility)
> pattern in Struts 1.3 is not going to be for "actions" per se
> (although anyone can always use the CoR pattern) but for creating an
> extensible RequestProcessor.  I may, as I said, be mistaken about
> that, but the general buzz has given me that impression.
> 
> Shey Rab Pawo




-- 
No one ever went blind looking at the bright side of life.

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

Re: Action call another action?

[Dakota Jack]

On 4/24/05, James Mitchell <[EMAIL PROTECTED]> wrote:
...
These people are actually the same
> person masquerading as alternate identities, which would be fine if they all
> didn't have the same PITA (see below) attitudes.  


You need to be careful about making these assertions, James.  


> What I find really sad is that even after
> several people have explained to this guy the errors in his ways and
> actions, in cut-throat clarity, he continues to spam the lists with his
> useless defunct ideas that nobody listens to.


You are obviously not happy, James.  But, you really should not let
this cloud the clear fact that many people have indicated an interest
in and an appreciation for in print.  I am not going to go through
that list, but you can easily if you like.  You won't, of course,
because you are not happy about things.

I have to tell you, however, that what you think about me is not only
none of my business but none of anyone else's business either.  That
is your business, which you have chosen to display publicly.


> By the
> way, the post you sent to Struts with your Micael account was held in the
> moderation queue, which you were obviously to careless to realize.  When
> that didn't arrive to the list, you followed up with one from the Dakota
> account.  How dumb do you think we are?  Dude, you're not fooling anyone.
> Oh, it gets better.  And after all that, the only thing you managed to
> accomplish was to piss off people here and on the Cocoon listnice job!


You need to know that all these perceived complications are not part
of my life.  You have no clue what is going on.  I don't either.  I
don't in the sense that I have no idea what a "moderation" queue is. 
I also do not pay attention to when things show up on what lists. 
They really are not that big a deal to me.


> This behavior has been discussed at length on and off list.  It has been
> determined that banning people who engage in this behavior has little effect
> at deterring it, and, in some cases, only adds fuel to the fire.


Whatever anyone thinks.  I am not happy that you are so agitated.  If
I could do something sensible to help, I would.  I do think that
people are generally more than capable of making their own decisions
about what they want to read.  There is little chance for competition
in the arean of ideas if those in power exercize that power to
extinguish ideas and submissions they find a thorn on their rose.

Jack


-- 
"You can lead a horse to water but you cannot make it float on its back."
~Dakota Jack~

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

Re: Action call another action?

[James Mitchell]

For the record, you are encouraged to ignore all statements made by Micael
McGrady, Dakota Jack, or Shey Rab Pawo.  These people are actually the same
person masquerading as alternate identities, which would be fine if they all
didn't have the same PITA (see below) attitudes.  His track record on this
list and others, has proven to be completely non-productive and, at best, a
general waste of everyone's time.  What I find really sad is that even after
several people have explained to this guy the errors in his ways and
actions, in cut-throat clarity, he continues to spam the lists with his
useless defunct ideas that nobody listens to.
It is still not known why this particular user chooses to take such drastic
measures to conceal his true identity.  The only thing worse than someone
trying to fool people by using different user accounts, is someone who is
too stupid to do it correctly.  Next time Micael, try to pay closer
attention as you participate here, other lists and TSS feedback.  By the
way, the post you sent to Struts with your Micael account was held in the
moderation queue, which you were obviously to careless to realize.  When
that didn't arrive to the list, you followed up with one from the Dakota
account.  How dumb do you think we are?  Dude, you're not fooling anyone.
Oh, it gets better.  And after all that, the only thing you managed to
accomplish was to piss off people here and on the Cocoon listnice job!
This kind of behavior is described by the following web page:
http://wiki.apache.org/struts/DefinePita
This behavior has been discussed at length on and off list.  It has been
determined that banning people who engage in this behavior has little effect
at deterring it, and, in some cases, only adds fuel to the fire.


--
James Mitchell
Software Engineer / Open Source Evangelist
Consulting / Mentoring / Freelance
EdgeTech, Inc.
678.910.8017
AIM:   jmitchtx
Yahoo: jmitchtx
MSN:   [EMAIL PROTECTED]

- Original Message - 
From: "Shey Rab Pawo" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" 
Sent: Saturday, April 23, 2005 2:44 PM
Subject: Re: Action call another action?

I may be mistaken but I think that the CoR (Chain of Responsibility)
pattern in Struts 1.3 is not going to be for "actions" per se
(although anyone can always use the CoR pattern) but for creating an
extensible RequestProcessor.  I may, as I said, be mistaken about
that, but the general buzz has given me that impression.
Shey Rab Pawo
On 4/21/05, Erik Weber <[EMAIL PROTECTED]> wrote:
That's the way I do it. If your Actions are light, as they should be, it
doesn't add a lot of code. Some redundant code is not a bad thing, it
can make things clearer. If you were to "chain" actions, then you'd be
going through the entire request processor chain again.
I think that Struts 1.3, with chain of responsibility implementation,
should allow chaining of actions without causing redundant processing,
but I can't say for sure (at least I hope it does).
Erik
Yen wrote:
> Hi,
>
> I have an action which save the data into the database, after the
> saving, I would like to forward to the listing page, where I have
> another action doing the listing.
>
> Should I repeat the same listing method (method list) in the save
> action itself..? Or, is there any better way?
>
> Thanks for advanced.
>
> rgds,
> Yen
>
> public ActionForward save(ActionMapping mapping, ActionForm form,
> HttpServletRequest request, HttpServletResponse response)
> {
>method save..
>method list..
>   return (mapping.findForward("afflist"));
> }
>
> public ActionForward listing(ActionMapping mapping, ActionForm form,
> HttpServletRequest request, HttpServletResponse response)
> {
>method list
>   return (mapping.findForward("afflist"));
> }
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


--
No one ever went blind looking at the bright side of life.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

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

Re: Action call another action?

[Shey Rab Pawo]

I may be mistaken but I think that the CoR (Chain of Responsibility)
pattern in Struts 1.3 is not going to be for "actions" per se
(although anyone can always use the CoR pattern) but for creating an
extensible RequestProcessor.  I may, as I said, be mistaken about
that, but the general buzz has given me that impression.

Shey Rab Pawo

On 4/21/05, Erik Weber <[EMAIL PROTECTED]> wrote:
> That's the way I do it. If your Actions are light, as they should be, it
> doesn't add a lot of code. Some redundant code is not a bad thing, it
> can make things clearer. If you were to "chain" actions, then you'd be
> going through the entire request processor chain again.
> 
> I think that Struts 1.3, with chain of responsibility implementation,
> should allow chaining of actions without causing redundant processing,
> but I can't say for sure (at least I hope it does).
> 
> Erik
> 
> 
> Yen wrote:
> 
> > Hi,
> >
> > I have an action which save the data into the database, after the
> > saving, I would like to forward to the listing page, where I have
> > another action doing the listing.
> >
> > Should I repeat the same listing method (method list) in the save
> > action itself..? Or, is there any better way?
> >
> > Thanks for advanced.
> >
> > rgds,
> > Yen
> >
> > public ActionForward save(ActionMapping mapping, ActionForm form,
> > HttpServletRequest request, HttpServletResponse response)
> > {
> >method save..
> >method list..
> >   return (mapping.findForward("afflist"));
> > }
> >
> > public ActionForward listing(ActionMapping mapping, ActionForm form,
> > HttpServletRequest request, HttpServletResponse response)
> > {
> >method list
> >   return (mapping.findForward("afflist"));
> > }
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 


-- 
No one ever went blind looking at the bright side of life.

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

Re: Action call another action?

[Michael Jouravlev]

> I have an action which save the data into the database, after the saving, I
> would like to forward to the listing page, where I have another action doing
> the listing.
> 
> Should I repeat the same listing method (method list) in the save action
> itself..? Or, is there any better way?

...

> whenever I did an add action, then go back to the listing page, whenever 
> I click the Next/Previous, it will add another record, and keep adding.

No. You have an action which shows item. It submits data to Save
Action. Save Action stores data in the database and redirects (not
forwards!) to the list. If you use redirect, you can reload your list
or do anything else.

The action which shows the list, must use session-scoped form bean (or
other session-scoped data), and store there the page number, if you
want to return to particular page. I am not sure what do you have to
do if you add or delete item, since you might need to repaginate.

Also read this: http://wiki.apache.org/struts/StrutsMultipleActionForms
You might like two action / two form approach. See example of Edit
Action and Save Action. Check out samle application here:
http://www.superinterface.com/rdapp/viewList.do Try to play with
Refrest/Back/Forward buttons. Try to resubmit the newly created item.

Michael.

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

Re: Action call another action?

[Yen]

The problem is, I use ValueList for the listing page, it will automaticaaly 
append the action=add when selecting the next/previous page.

so, after I add the record, it will go to the listing page (return 
(mapping.findForward("afflist"))), at the same time, it will append the 
action=add (base on the previous action)..

That means, whenever I did an add action, then go back to the listing page, 
whenever I click the Next/Previous, it will add another record, and keep adding.

I tried to do like this..
   

 

In the add action, I forward to "myafflist" rather than the usual "afflist".. 
the listing page still append the action=add after I did the add action

http://localhost:7001/myweb/Affiliations.action?aff_name=h&remarks=h&pagingPage=2&year_joined=h&execute=list&execute=add&;

it sounds funny, but at least... it works now..

anyone any better idea?


- Original Message - 
From: "Erik Weber" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" 
Sent: Friday, April 22, 2005 10:48 AM
Subject: Re: Action call another action?


> That's the way I do it. If your Actions are light, as they should be, it 
> doesn't add a lot of code. Some redundant code is not a bad thing, it 
> can make things clearer. If you were to "chain" actions, then you'd be 
> going through the entire request processor chain again.
> 
> I think that Struts 1.3, with chain of responsibility implementation, 
> should allow chaining of actions without causing redundant processing, 
> but I can't say for sure (at least I hope it does).
> 
> Erik
> 
> 
> Yen wrote:
> 
>> Hi,
>>
>> I have an action which save the data into the database, after the 
>> saving, I would like to forward to the listing page, where I have 
>> another action doing the listing.
>>
>> Should I repeat the same listing method (method list) in the save 
>> action itself..? Or, is there any better way?
>>
>> Thanks for advanced.
>>
>> rgds,
>> Yen
>>
>> public ActionForward save(ActionMapping mapping, ActionForm form, 
>> HttpServletRequest request, HttpServletResponse response)
>> {
>>method save..
>>method list..
>>   return (mapping.findForward("afflist"));
>> }
>>
>> public ActionForward listing(ActionMapping mapping, ActionForm form, 
>> HttpServletRequest request, HttpServletResponse response)
>> {
>>method list
>>   return (mapping.findForward("afflist"));
>> }
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

Re: Action call another action?

[Erik Weber]

Let me just make sure I'm being clear, since you appear to use separate 
Actions whereas I typically use one.

I do it like this:
execute( . . .) {
 //switch
 case view:
   getDelegate().doViewStuff();
   break;
 case save:
   getDelegate().doSaveStuff();
   getDelegate().doViewStuff();
   break;
 . . .
}
Even though you have a different design, I think we're talking about the 
same thing. Please disregard if we're not.

Erik

Erik Weber wrote:
That's the way I do it. If your Actions are light, as they should be, 
it doesn't add a lot of code. Some redundant code is not a bad thing, 
it can make things clearer. If you were to "chain" actions, then you'd 
be going through the entire request processor chain again.

I think that Struts 1.3, with chain of responsibility implementation, 
should allow chaining of actions without causing redundant processing, 
but I can't say for sure (at least I hope it does).

Erik
Yen wrote:
Hi,
I have an action which save the data into the database, after the 
saving, I would like to forward to the listing page, where I have 
another action doing the listing.

Should I repeat the same listing method (method list) in the save 
action itself..? Or, is there any better way?

Thanks for advanced.
rgds,
Yen
public ActionForward save(ActionMapping mapping, ActionForm form, 
HttpServletRequest request, HttpServletResponse response)
{
   method save..
   method list..
  return (mapping.findForward("afflist"));
}

public ActionForward listing(ActionMapping mapping, ActionForm form, 
HttpServletRequest request, HttpServletResponse response)
{
   method list
  return (mapping.findForward("afflist"));
}

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

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

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

Re: Action call another action?

[Erik Weber]

That's the way I do it. If your Actions are light, as they should be, it 
doesn't add a lot of code. Some redundant code is not a bad thing, it 
can make things clearer. If you were to "chain" actions, then you'd be 
going through the entire request processor chain again.

I think that Struts 1.3, with chain of responsibility implementation, 
should allow chaining of actions without causing redundant processing, 
but I can't say for sure (at least I hope it does).

Erik
Yen wrote:
Hi,
I have an action which save the data into the database, after the 
saving, I would like to forward to the listing page, where I have 
another action doing the listing.

Should I repeat the same listing method (method list) in the save 
action itself..? Or, is there any better way?

Thanks for advanced.
rgds,
Yen
public ActionForward save(ActionMapping mapping, ActionForm form, 
HttpServletRequest request, HttpServletResponse response)
{
   method save..
   method list..
  return (mapping.findForward("afflist"));
}

public ActionForward listing(ActionMapping mapping, ActionForm form, 
HttpServletRequest request, HttpServletResponse response)
{
   method list
  return (mapping.findForward("afflist"));
}

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

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

Action call another action?

[Yen]

Hi,
I have an action which save the data into the database, after the saving, I 
would like to forward to the listing page, where I have another action doing 
the listing.

Should I repeat the same listing method (method list) in the save action 
itself..? Or, is there any better way?

Thanks for advanced.
rgds,
Yen
public ActionForward save(ActionMapping mapping, ActionForm form, 
HttpServletRequest request, HttpServletResponse response)
{
   method save..
   method list..
  return (mapping.findForward("afflist"));
}

public ActionForward listing(ActionMapping mapping, ActionForm form, 
HttpServletRequest request, HttpServletResponse response)
{
   method list
  return (mapping.findForward("afflist"));
} 

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