I was thinking something like this:

        <action name="Foo" class="com.opensymphony.xwork.SimpleAction">
            <param name="foo">17</param>
            <param name="bar">23</param>
            <result name="success" type="chain">
                <param name="actionName">Bar</param>
            </result>
            <interceptor-ref name="debugStack"/>
            <interceptor-ref name="defaultStack"/>
                <command name="myCommand" alias="fooCommand" method="myFooAction">
                        <param name="baz">100</param>
                </command>
        </action>

Where we define commands that are mapped to an alias and a method to execute (which is 
optional and would default to doMyCommand() in this case). 

If we did this, we could make it where name is an optional attribute of action and, if 
present, creates a default command alias with a method mapping of execute(). Then, 
rather than using the Action Interface, which only defines the execute() method, you'd 
just use reflection to find ALL execute methods, either execute() or doMyCommand() or 
whatever you map. Notice that in Xwork, ActionSupport's execute() method only returns 
SUCCESS, it doesn't actually have to do anything, because the Interceptors take care 
of things like validation. 

All execute methods, no matter what they're named, would need to be zero arg methods 
and return a String... Or if it returns something besides a String I suppose we could 
just take not throwing an exception as SUCCESS, and throwing an exception as ERROR. 

Thoughts?

Jason

> -----Original Message-----
> From: Matt Ho [mailto:[EMAIL PROTECTED]] 
> Sent: Wednesday, February 19, 2003 9:37 AM
> To: [EMAIL PROTECTED]
> Subject: RE: [OS-webwork] re: some suggestion about ww2.0
> 
> 
> I think this would be a good thing to put in an interceptor 
> and not in the core XWork framework.  However, putting a 
> param tag inside an action might not be a bad idea.
> 
> <action name="create">
>   <param name="method">transferAccount</param>
>   <param name="param1">acct1</param>
>   <param name="param2">acct2</param>
>   <interceptor-ref name="pojo"/>
>   ...
> </action> 
> 
> --
> Matt Ho
> Principal
> Indigo Egg, Inc.
> http://www.indigoegg.com/
> 
> 
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]] 
> On Behalf Of 
> > Jason Carreira
> > Sent: Wednesday, February 19, 2003 5:25 AM
> > To: [EMAIL PROTECTED]
> > Subject: FW: RE: [OS-webwork] re: some suggestion about ww2.0
> > 
> > Hmmm... This has me thinking. Maybe we could allow command driven
> actions
> > to specify the method to call (defaulting to doCommandName) 
> to execute
> the
> > action for that command?
> > 
> > What do we do if the method doesn't return String? Should we try to
> catch
> > exceptions, then return ERROR if we catch one, or return SUCCESS if
> not?
> > 
> > Do we need the Action interface in this case?
> > 
> > Jason
> > 
> > -----Original Message-----
> > From: 顾天扬 [mailto:[EMAIL PROTECTED]]
> > Sent: Wednesday, February 19, 2003 12:25 AM
> > To: Jason Carreira
> > Subject: RE: RE: [OS-webwork] re: some suggestion about ww2.0
> > 
> > 
> > 
> > 
> > Why could we call common methods of a POJO javabean from some new
> tags?
> > 
> > 
> > 
> > My problem comes from below situation:
> > 
> > 
> > 
> > My system is a 3-tier system, web tier - middle tier - database.
> > 
> > In the middle tier, system is composed of entities and 
> business logic.
> > 
> > 
> > 
> >             An example of a business logic like this:
> > 
> > 
> > 
> >             public class AccountManager
> > 
> >             {
> > 
> >                     //create account
> > 
> >                 public void createAccount(Account account)
> > 
> >                 {
> > 
> >                     ...
> > 
> >                 }
> > 
> > 
> > 
> >                 //transfer amount between accounts
> > 
> >                 public void transferAccount(String acct1,String
> acct2,
> > long amount)
> > 
> >                 {
> > 
> >                     ...
> > 
> >                 }
> > 
> > 
> > 
> >                 //get account balance
> > 
> >                     public balance getAccountBalance(String acct1)
> > 
> >                     {
> > 
> >                         ...
> > 
> >                     }
> > 
> > 
> > 
> >                     ...
> > 
> >             }
> > 
> > 
> > 
> > In ww1.x, AccountManager cant be directly used as "Control" for
> webwork
> > 
> > view technologies. I must translate AccountManager to many 
> "Action"s.
> Each
> > 
> > action spreads method params and result to action fields, like this:
> > 
> > 
> > 
> >             public class CreateAccountAction extends ActionSupport {
> > 
> > 
> > 
> >                     Account account;
> > 
> >                     public Account getAccount(){};
> > 
> >                     public void setAccount(Account account){};
> > 
> > 
> > 
> >                     public void execute()
> > 
> >                     {
> > 
> >                             //call middle tier logic
> > 
> >
> getAccountManger().createAccount(account);
> > 
> >                     }
> > 
> > 
> > 
> >             }
> > 
> > 
> > 
> > I know the tedious translation work could be automatically 
> by xdoclet.
> > 
> > But if ww2.0 view technologies could support POJO such as
> AccountManager
> > 
> > as "Logic" layer, it'll be preferred for programmers like me.
> > 
> > ----- Original Message -----
> > 
> > From:"Jason Carreira" <[EMAIL PROTECTED]>
> > 
> > To:<[EMAIL PROTECTED]>
> > 
> > Subject:RE: [OS-webwork] re: some suggestion about ww2.0
> > 
> > Date:Wed, 19 Feb 2003 12:33:27 +0800
> > 
> >  >>
> > 
> >  >>
> > 
> >  >>
> > 
> >  >> Maybe I asked a foolish question or my english is poor
> > 
> >  >> ( I am not a native English Speaker). But please correct
> > 
> >  >> me if I am wrong.
> > 
> >  >>
> > 
> >  >> My main suggestion is remove the restriction of Action layer.
> > 
> >  >> Could we just use POJO as "Action"? If it's possible, we
> > 
> >  >> could say proundly, " No formbeans, No actions " :)
> > 
> >  >>
> > 
> >  >>             Gu Tianyang
> > 
> >  >>             [EMAIL PROTECTED]
> > 
> >  >
> > 
> >  >The problem here is that you'll want your web app to DO something.
> > 
> >  >Without an Action, how will it be triggered to do something? Is
> > 
> >  >populating a javabean the only thing you're looking to do?
> > 
> >  >
> > 
> >  >Jason
> > 
> >  >
> > 
> >  >
> > 
> >  >-------------------------------------------------------
> > 
> >  >This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
> > 
> >  >The most comprehensive and flexible code editor you can use.
> > 
> >  >Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day
> Trial.
> > 
> >  >www.slickedit.com/sourceforge
> > 
> >  >_______________________________________________
> > 
> >  >Opensymphony-webwork mailing list
> > 
> >  >[EMAIL PROTECTED]
> > 
> >  >https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
> > 
> >  >
> > 
> >  >
> > 
> > 
> > ______________________________________
> > 
> > 
> > ===================================================================
> > 手机语音聊天国内长途5分钟/1元、帅哥美女靓照尽在爱情快递
> > (http://love.sina.com.cn) 
> > 手机短信发送m到888810,免费获得新浪15M任你邮邮箱!
> > (http://vip.sina.com/love_send/lover.html)
> > 缤纷下载俱乐部 每月5元图片铃声随心换
> > (http://sms.sina.com.cn/act/member.html)
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email is sponsored by: SlickEdit Inc. Develop 
> an edge. The 
> > most comprehensive and flexible code editor you can use. 
> Code faster. 
> > C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. 
> > www.slickedit.com/sourceforge 
> > _______________________________________________
> > Opensymphony-webwork mailing list 
> > [EMAIL PROTECTED]
> > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SlickEdit Inc. Develop an 
> edge. The most comprehensive and flexible code editor you can 
> use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 
> 30-Day Trial. www.slickedit.com/sourceforge 
> _______________________________________________
> Opensymphony-webwork mailing list 
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
> 


-------------------------------------------------------
This SF.net email is sponsored by: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork

Reply via email to