RE: Problem with action chaining

2004-01-02 Thread Tim Lucia
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:[EMAIL PROTECTED] 
> 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:[EMAIL PROTECTED]
> >> 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
> >

RE: Problem with action chaining

2004-01-01 Thread Ted Husted
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:[EMAIL PROTECTED]
>> 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
>>

RE: Problem with action chaining

2004-01-01 Thread Tim Lucia
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:[EMAIL PROTECTED] 
> 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 



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



RE: Problem with action chaining

2003-12-31 Thread Ted Husted
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: Problem with action chaining

2003-12-31 Thread Tim Lucia
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.

Thanks,
Tim

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, December 31, 2003 4:04 AM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: Problem with action chaining
> 
> 
> Hi ,
> As pointed out by Mohan, Action chainning is not a good 
> design practice... You can forward from one action to another 
> but they should eb performing completely independent units of 
> work.If two actions are used to complete only bits of work to 
> complete one logical response, then it is a bad design. There 
> is a discussion thread about action chainning in mail archive.



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



Re: Problem with action chaining

2003-12-31 Thread Domingo A. Rodriguez S.

Can you post the naughty class source code and the stack trace so we can
check the problem better?

Regards,
Domingo A. Rodriguez S.

 --- [EMAIL PROTECTED] escribió: > Hi, 
> 
>  
> 
> I have a problem with action chaining. My action tag 
> 
>  
> type="com.epolicy.arch.brokerage.web.agency.AgencyAction"
> 
> name="agencyForm"
> 
> validate="true"
> 
> parameter="create"
> 
> scope="request">
> 
> 
> 
> 
> 
> 
> 
> 
> 
>  
> 
>  
> 
> forwards control to the following:
> 
>  
> 
>  
> type="com.epolicy.arch.brokerage.web.agency.AgencyCreateAction"
> 
> name="agencyCreateForm"
> 
> validate="true"
> 
> scope="session">
> 
> 
> 
> 
> 
>  
> 
> Now AgencyCreateForm extends AgencyForm and AgencyCreateAction extends
> AgencyAction. 
> 
>  
> 
> When the derived class AgencyCreateAction tries to type cast the
> AgencyCreateForm in the execute() method, it throws a type cast
> exception. This is because no instance of AgencyCreateForm is created
> and it still persists the instance of AgencyForm. 
> 
>  
> 
> Can anyone guide me as to how I can resolve this problem. 
> 
>  
> 
> Regards,
> 
> Kavita C. 
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, December 31, 2003 10:19 AM
> To: Kavita Cardoz
> Subject: WELCOME to [EMAIL PROTECTED]
> 
>  
> 
> Hi! This is the ezmlm program. I'm managing the
> 
> [EMAIL PROTECTED] mailing list.
> 
>  
> 
> I'm working for my owner, who can be reached
> 
> at [EMAIL PROTECTED]
> 
>  
> 
> Acknowledgment: I have added the address
> 
>  
> 
>[EMAIL PROTECTED]
> 
>  
> 
> to the struts-user mailing list.
> 
>  
> 
> Welcome to [EMAIL PROTECTED]
> 
>  
> 
> Please save this message so that you know the address you are
> 
> subscribed under, in case you later want to unsubscribe or change your
> 
> subscription address.
> 
>  
> 
>  
> 
> --- Administrative commands for the struts-user list ---
> 
>  
> 
> I can handle administrative requests automatically. Please
> 
> do not send them to the list address! Instead, send
> 
> your message to the correct command address:
> 
>  
> 
> To subscribe to the list, send a message to:
> 
><[EMAIL PROTECTED]>
> 
>  
> 
> To remove your address from the list, send a message to:
> 
><[EMAIL PROTECTED]>
> 
>  
> 
> Send mail to the following for info and FAQ for this list:
> 
><[EMAIL PROTECTED]>
> 
><[EMAIL PROTECTED]>
> 
>  
> 
> Similar addresses exist for the digest list:
> 
><[EMAIL PROTECTED]>
> 
><[EMAIL PROTECTED]>
> 
>  
> 
> To get messages 123 through 145 (a maximum of 100 per request), mail:
> 
><[EMAIL PROTECTED]>
> 
>  
> 
> To get an index with subject and author for messages 123-456 , mail:
> 
><[EMAIL PROTECTED]>
> 
>  
> 
> They are always returned as sets of 100, max 2000 per request,
> 
> so you'll actually get 100-499.
> 
>  
> 
> To receive all messages with the same subject as message 12345,
> 
> send an empty message to:
> 
><[EMAIL PROTECTED]>
> 
>  
> 
> The messages do not really need to be empty, but I will ignore
> 
> their content. Only the ADDRESS you send to is important.
> 
>  
> 
> You can start a subscription for an alternate address,
> 
> for example "[EMAIL PROTECTED]", just add a hyphen and your
> 
> address (with '=' instead of '@') after the command word:
> 
> <[EMAIL PROTECTED]>
> 
>  
> 
> To stop subscription for this address, mail:
> 
> <[EMAIL PROTECTED]>
> 
>  
> 
> In both cases, I'll send a confirmation message to that address. When
> 
> you receive it, simply reply to it to complete your subscription.
> 
>  
> 
> If despite following these instructions, you do not get the
> 
> desired results, please contact my owner at
> 
> [EMAIL PROTECTED] Please be patient, my owner is a
> 
> lot slower than I am ;-)
> 
>  
> 
> --- Enclosed is a copy of the request I received.
> 
>  
> 
> Return-Path: <[EMAIL PROTECTED]>
> 
> Received: (qmail 38403 invoked from network); 31 Dec 2003 04:49:08 -
> 
> Received: from unknown (HELO mumbai2.ezbroadnet.com) (203.124.136.26)
> 
>   by daedalus.apache.org with SMTP; 31 Dec 2003 04:49:08 -
> 
> Received: from ind-spz7gwy003.mastek.com (meghdoot.mastek.com
> [203.124.144.12])
> 
> by mumbai2.ezbroadnet.com (8.11.7p1+Sun/8.11.7) with SMTP id
> hBV4k7A06598
> 
> for
> <[EMAIL PROTECTED]
> ta.apache.org>; Wed, 31 Dec 2003 10:16:07 +0530 (IST)
> 
> Received: FROM ind-spz7gwy002.mastek.com BY ind-spz7gwy003.mastek.com ;
> Wed Dec 31 10:16:36 2003 +0500
> 
> Received: from IND-SPZ7ECL001.mastek.com (unverified) by 
> 
> ind-spz7gwy002.mastek.com (Content Technologies SMTPRS 4.3.12) with
> ESMTP 
> 
> id <[EMAIL PROTECTED]> for 
> 
>  
> <[EMAIL PROTECTED]
> ta.apache.org>
> 
>; Wed, 31 Dec 2003 10:16:36 +0530
> 
> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
> 
> content-class: urn:content-classes:message
> 
> MIME-Version: 1.0

RE: Problem with action chaining

2003-12-31 Thread shirishchandra.sakhare
Hi ,
As pointed out by Mohan, Action chainning is not a good design practice...
You can forward from one action to another but they should eb performing completely 
independent units of work.If two actions are used to complete only bits of work to 
complete one logical response, then it is a bad design. There is a discussion thread 
about action chainning in mail archive.

Now about your question.

What do u mean by forwarding from action 1 tomaction 2?Because if AgencyAction  says 
mapping.findFOrward("create")
 then this should work as the forward will agin cause the form instance to be created 
or retrieved from session...


But if you are callign execute of the AgencyCreateAction from first action, then it 
will not work.


HTH.
regards,
Shirish



-Original Message-
From: Mohan Radhakrishnan [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 31, 2003 6:38 AM
To: 'Struts Users Mailing List'
Subject: RE: Problem with action chaining


We use base forms too but we use sub-forms in both action mappings. It works
for us if we use sub-forms with action chaining like this.

  Our action chains are very minimal though because it is not recommended
design practice.
Mohan

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 31, 2003 10:26 AM
To: [EMAIL PROTECTED]
Subject: Problem with action chaining


Hi, 

 

I have a problem with action chaining. My action tag 











 

 

forwards control to the following:

 







 

Now AgencyCreateForm extends AgencyForm and AgencyCreateAction extends
AgencyAction. 

 

When the derived class AgencyCreateAction tries to type cast the
AgencyCreateForm in the execute() method, it throws a type cast
exception. This is because no instance of AgencyCreateForm is created
and it still persists the instance of AgencyForm. 

 

Can anyone guide me as to how I can resolve this problem. 

 

Regards,

Kavita C. 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 
Sent: Wednesday, December 31, 2003 10:19 AM
To: Kavita Cardoz
Subject: WELCOME to [EMAIL PROTECTED]

 

Hi! This is the ezmlm program. I'm managing the

[EMAIL PROTECTED] mailing list.

 

I'm working for my owner, who can be reached

at [EMAIL PROTECTED]

 

Acknowledgment: I have added the address

 

   [EMAIL PROTECTED]

 

to the struts-user mailing list.

 

Welcome to [EMAIL PROTECTED]

 

Please save this message so that you know the address you are

subscribed under, in case you later want to unsubscribe or change your

subscription address.

 

 

--- Administrative commands for the struts-user list ---

 

I can handle administrative requests automatically. Please

do not send them to the list address! Instead, send

your message to the correct command address:

 

To subscribe to the list, send a message to:

   <[EMAIL PROTECTED]>

 

To remove your address from the list, send a message to:

   <[EMAIL PROTECTED]>

 

Send mail to the following for info and FAQ for this list:

   <[EMAIL PROTECTED]>

   <[EMAIL PROTECTED]>

 

Similar addresses exist for the digest list:

   <[EMAIL PROTECTED]>

   <[EMAIL PROTECTED]>

 

To get messages 123 through 145 (a maximum of 100 per request), mail:

   <[EMAIL PROTECTED]>

 

To get an index with subject and author for messages 123-456 , mail:

   <[EMAIL PROTECTED]>

 

They are always returned as sets of 100, max 2000 per request,

so you'll actually get 100-499.

 

To receive all messages with the same subject as message 12345,

send an empty message to:

   <[EMAIL PROTECTED]>

 

The messages do not really need to be empty, but I will ignore

their content. Only the ADDRESS you send to is important.

 

You can start a subscription for an alternate address,

for example "[EMAIL PROTECTED]", just add a hyphen and your

address (with '=' instead of '@') after the command word:

<[EMAIL PROTECTED]>

 

To stop subscription for this address, mail:

<[EMAIL PROTECTED]>

 

In both cases, I'll send a confirmation message to that address. When

you receive it, simply reply to it to complete your subscription.

 

If despite following these instructions, you do not get the

desired results, please contact my owner at

[EMAIL PROTECTED] Please be patient, my owner is a

lot slower than I am ;-)

 

--- Enclosed is a copy of the request I received.

 

Return-Path: <[EMAIL PROTECTED]>

Received: (qmail 38403 invoked from network); 31 Dec 2003 04:49:08 -

Received: from unknown (HELO mumbai2.ezbroadnet.com) (203.124.136.26)

  by daedalus.apache.org with SMTP; 31 Dec 2003 04:49:08 -

Received: from ind-spz7gwy003.mastek.com (meghdoot.mastek.com
[203.124.144.12])

by mumbai2.ezbroadnet.com (8.11.7p1+Sun/8.11.7) with SMTP id
hBV4k7A06598

for
<[EMAIL PROTECTED]
ta.apache.org>; Wed, 31 D

RE: Problem with action chaining

2003-12-30 Thread Mohan Radhakrishnan
We use base forms too but we use sub-forms in both action mappings. It works
for us if we use sub-forms with action chaining like this.

  Our action chains are very minimal though because it is not recommended
design practice.
Mohan

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 31, 2003 10:26 AM
To: [EMAIL PROTECTED]
Subject: Problem with action chaining


Hi, 

 

I have a problem with action chaining. My action tag 











 

 

forwards control to the following:

 







 

Now AgencyCreateForm extends AgencyForm and AgencyCreateAction extends
AgencyAction. 

 

When the derived class AgencyCreateAction tries to type cast the
AgencyCreateForm in the execute() method, it throws a type cast
exception. This is because no instance of AgencyCreateForm is created
and it still persists the instance of AgencyForm. 

 

Can anyone guide me as to how I can resolve this problem. 

 

Regards,

Kavita C. 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] 
Sent: Wednesday, December 31, 2003 10:19 AM
To: Kavita Cardoz
Subject: WELCOME to [EMAIL PROTECTED]

 

Hi! This is the ezmlm program. I'm managing the

[EMAIL PROTECTED] mailing list.

 

I'm working for my owner, who can be reached

at [EMAIL PROTECTED]

 

Acknowledgment: I have added the address

 

   [EMAIL PROTECTED]

 

to the struts-user mailing list.

 

Welcome to [EMAIL PROTECTED]

 

Please save this message so that you know the address you are

subscribed under, in case you later want to unsubscribe or change your

subscription address.

 

 

--- Administrative commands for the struts-user list ---

 

I can handle administrative requests automatically. Please

do not send them to the list address! Instead, send

your message to the correct command address:

 

To subscribe to the list, send a message to:

   <[EMAIL PROTECTED]>

 

To remove your address from the list, send a message to:

   <[EMAIL PROTECTED]>

 

Send mail to the following for info and FAQ for this list:

   <[EMAIL PROTECTED]>

   <[EMAIL PROTECTED]>

 

Similar addresses exist for the digest list:

   <[EMAIL PROTECTED]>

   <[EMAIL PROTECTED]>

 

To get messages 123 through 145 (a maximum of 100 per request), mail:

   <[EMAIL PROTECTED]>

 

To get an index with subject and author for messages 123-456 , mail:

   <[EMAIL PROTECTED]>

 

They are always returned as sets of 100, max 2000 per request,

so you'll actually get 100-499.

 

To receive all messages with the same subject as message 12345,

send an empty message to:

   <[EMAIL PROTECTED]>

 

The messages do not really need to be empty, but I will ignore

their content. Only the ADDRESS you send to is important.

 

You can start a subscription for an alternate address,

for example "[EMAIL PROTECTED]", just add a hyphen and your

address (with '=' instead of '@') after the command word:

<[EMAIL PROTECTED]>

 

To stop subscription for this address, mail:

<[EMAIL PROTECTED]>

 

In both cases, I'll send a confirmation message to that address. When

you receive it, simply reply to it to complete your subscription.

 

If despite following these instructions, you do not get the

desired results, please contact my owner at

[EMAIL PROTECTED] Please be patient, my owner is a

lot slower than I am ;-)

 

--- Enclosed is a copy of the request I received.

 

Return-Path: <[EMAIL PROTECTED]>

Received: (qmail 38403 invoked from network); 31 Dec 2003 04:49:08 -

Received: from unknown (HELO mumbai2.ezbroadnet.com) (203.124.136.26)

  by daedalus.apache.org with SMTP; 31 Dec 2003 04:49:08 -

Received: from ind-spz7gwy003.mastek.com (meghdoot.mastek.com
[203.124.144.12])

by mumbai2.ezbroadnet.com (8.11.7p1+Sun/8.11.7) with SMTP id
hBV4k7A06598

for
<[EMAIL PROTECTED]
ta.apache.org>; Wed, 31 Dec 2003 10:16:07 +0530 (IST)

Received: FROM ind-spz7gwy002.mastek.com BY ind-spz7gwy003.mastek.com ;
Wed Dec 31 10:16:36 2003 +0500

Received: from IND-SPZ7ECL001.mastek.com (unverified) by 

ind-spz7gwy002.mastek.com (Content Technologies SMTPRS 4.3.12) with
ESMTP 

id <[EMAIL PROTECTED]> for 

 
<[EMAIL PROTECTED]
ta.apache.org>

   ; Wed, 31 Dec 2003 10:16:36 +0530

X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0

content-class: urn:content-classes:message

MIME-Version: 1.0

Content-Type: multipart/alternative; 

boundary="_=_NextPart_001_01C3CF59.10A528F8"

Disposition-Notification-To: <[EMAIL PROTECTED]>

Subject: RE: confirm subscribe to [EMAIL PROTECTED]

Date: Wed, 31 Dec 2003 10:16:33 +0530

Message-ID:
<[EMAIL PROTECTED]>

X-MS-Has-Attach: 

X-MS-TNEF-Correlator: 

Thread-Topic: confirm subscribe to [EMAIL PROTECTED]

Thread-Index: AcPPWOjsISsYE5GDRbixny8C3KbkqAAACKhA

From: <[EMAIL PROTECTED]>

To:
<[EMAIL PROTECTED]
ta.apache.org>

X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

 

This is a multi-part message in MIME format.

 

--_=_NextPart_001_01C