Client doesn't need to have action configuration. It's the server's job to look up configuration and decide what interceptors should be applied. Both alternatives requires the client to send package/action name, for looking up in configuration. Difference being that when sending action with params filled, we don't need to parse them and put into the action, since client does this. This is how it's done in WW1, and it seemed to be quite good. Why should we need to involve parsing if all the time we're in Object domain?
Besides, I think one of the strong points in webwork is its simplicity, so having in core simple Client dispatching is enought (like in WW1), and other functionalities that are not essential for someone that just wants basic Client Action invocation, maybe shouldn't go in core. Or maybe basic client dispatcher in xwork, and the rest of the stuff in webwork, since other transports (RMI) could use basic stuff from xwork, but not depending on webwork... Not sure also, just thinking out loud, and trying to gather opinions. On Wednesday 17 December 2003 15:42, Jason Carreira wrote: > I think it's probably easier to send just the action name and > parameters... This also keeps the client from having to have the action > configuration, and allows the server can update which Action class > "action1" points to. I agree that you shouldn't need a special > configuration for Actions you can execute from the client. > > I'm not sure about the added functionality... Those sound like nice > things to have... Fernando, why do you think those shouldn't go into the > core? > > Jason > > > -----Original Message----- > > From: Fernando Martins [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, December 17, 2003 6:10 AM > > To: [EMAIL PROTECTED] > > Subject: Re: [OS-webwork] Client Dispatcher > > > > > > > > Still a few words on this subject, > > I checked the work that Ben Alex has done and attached to > > http://jira.opensymphony.com/secure/ViewIssue.jspa?key=WW-234 > > It's seems like quite good stuff, and big thanks goes to Ben. > > I just think that maybe it's too much specific to be included in the > > xwork/webwork2 core. > > Besides, there are a few things that I disagree with what Ben > > did. It shouldn't be necessary to create special action and > > result configuration. Any action configured allready should > > be able to be called from the Client. > > If action is not sent over network but only > > actionName+parameters, it is > > necessary to set the parameters on the action using ognl > > which takes cpu > > time. If user sends the action allready with all parameters > > set, it's much > > simpler and faster. > > > > As I see it, there should be basic functionality (like in > > WW1) included in > > xwork/ww2 to allow to just simply call an action, and the > > rest (SSL+progress > > notification+Automatic IO retries) should go to webwork-extensions or > > something like that. > > Please comment, because most probably I'm just too > > unexperienced to understand > > all details envolved. > > > > Anyway, thanks > > Fernando > > > > On Wednesday 17 December 2003 11:37, Fernando Martins wrote: > > > I've been migrating WW1 code that handles Client Dispatching (from > > > Applet or Swing) using servlets. Like Hani said, it wasn't > > > > too hard, > > > > > and it's working quite nicely. I wrote a ClientActionProxy which is > > > sent over the network with the action in it (in WW1 only the action > > > was sent), and on the server side it executes the action inside. > > > It returns to the client an ActionResult (with Action and > > > > resultCode, just > > > > > like WW1). > > > The only thing now missing is that it doesn't care for any > > > > configuration, > > > > > specially interceptors, because this is done in > > > > DefaultActionInvocation. > > > > > It also doesn't care for components. > > > So I guess to anchieve optimal behaviour, it should on the > > > > server side, > > > > > look up the configuration, and run all the interceptors, > > > > similar to what > > > > > DefaultActionInvocation does. > > > Probably there should be a customized version of > > > > DefaultActionInvocation > > > > > that doesn't just create a newly fresh action, but uses the > > > > action sent > > > > > over the network by the client. And it also doesn't have > > > > sense to run some > > > > > of the Interceptors like for example ParametersInterceptor, > > > > because dynamic > > > > > parameters should allready be set in the action that the > > > > client built. Is > > > > > this a good direction, or am I missing something? > > > > > > Thanks > > > Fernando > > > > > > > > > > > > ------------------------------------------------------- > > > This SF.net email is sponsored by: IBM Linux Tutorials. Become an > > > expert in LINUX or just sharpen your skills. Sign up for > > > > IBM's Free > > > > > Linux Tutorials. Learn everything from the bash shell to > > > > sys admin. > > > > > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > > > _______________________________________________ > > > Opensymphony-webwork mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: IBM Linux Tutorials. > > Become an expert in LINUX or just sharpen your skills. Sign > > up for IBM's Free Linux Tutorials. Learn everything from the > > bash shell to sys admin. Click now! > > http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > > > > _______________________________________________ > > Opensymphony-webwork mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > > ------------------------------------------------------- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=Click > _______________________________________________ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
