Re: [OS-webwork] Commands implemented
Jason Carreira wrote: action name=commandTest class=com.opensymphony.xwork.SimpleAction param name=foo123/param result name=error type=chain param name=actionNamebar/param /result interceptor-ref name=static-params/ command name=myCommand method=commandMethod param name=bar456/param result name=success type=chain param name=actionNamefoo/param /result interceptor-ref name=logger/ /command /action Why are params declared explicitly? What's wrong with finding them implicitly, as is done in WebWork? Sounds like a refactoring disaster waiting to happen. Any configuration that is mostly just duplication of code is a bad idea IMHO. Also, it is in general VITAL that we try to keep the configuration required for each action/command down to a minimum. Consider the above when you have 50-100 commands/actions. That's a lot of stuff to keep track of. This should be the last major change to configuration. The only other thing I want to do, and I just thought of this while I was writing this, is to make name optional on the Action and have it not create a runtime ActionConfig for the action itself if there is no name, although you could have several commands underneath the action which would be configured. Sounds ok. I also refactored the names of the config classes. Configuration - ConfigurationProvider ConfigurationFactory - ConfigurationProviderFactory DefaultConfiguration - DefaultConfigurationProvider Why not XMLConfigurationProvider? I mean, that's what it is. SimpleConfiguration - SimpleConfigurationProvider Why not TestConfigurationProvider? I mean, that's what it is. I've also created 2 new classes in the ActionConfig class hierarchy to support commands: ActionCommand ^ | ActionConfig ^ | HierarchicalActionConfig ActionCommand has: methodName Interceptors Parameters Results resultParameters ActionConfig adds: Class clazz TypeConverter HierarchicalActionConfig adds: Commands ActionConfig is the runtime datastructure, the other 2 are used on the programmatic side. Ok, so go ahead and start making fun of my class naming, but you'd better have some better ideas :-) See above. I'll write another email with questions about this stuff. Oh, and I think there might be more major changes to it ;-) /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Commands implemented
-Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED] Why are params declared explicitly? What's wrong with finding them implicitly, as is done in WebWork? Sounds like a refactoring disaster waiting to happen. Any configuration that is mostly just duplication of code is a bad idea IMHO. There are 2 types of parameterization, and you're free to use either or both. The params in the configuration are static params which are intended to parameterize a reusable Action for one or more aliases. For instance, if you had an email action you might parameterize it with the server address, etc. Also, it is in general VITAL that we try to keep the configuration required for each action/command down to a minimum. Consider the above when you have 50-100 commands/actions. That's a lot of stuff to keep track of. You don't HAVE to put params, etc. into the config, but you can if you need to. Why not XMLConfigurationProvider? I mean, that's what it is. Sure, that sounds ok. SimpleConfiguration - SimpleConfigurationProvider Why not TestConfigurationProvider? I mean, that's what it is. Sure. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Commands implemented
Jason Carreira wrote: There are 2 types of parameterization, and you're free to use either or both. The params in the configuration are static params which are intended to parameterize a reusable Action for one or more aliases. For instance, if you had an email action you might parameterize it with the server address, etc. Ok, so it's more like config stuff. I see. Right, we've covered this before. My bad. You don't HAVE to put params, etc. into the config, but you can if you need to. IIRC we argued about this before, and I think my position was that you'd typically want configuration to live elsewhere, but, as you said just don't use it (except that it becomes a built-in anti-pattern). /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Commands implemented
-Original Message- From: Rickard Öberg [mailto:[EMAIL PROTECTED] IIRC we argued about this before, and I think my position was that you'd typically want configuration to live elsewhere, but, as you said just don't use it (except that it becomes a built-in anti-pattern). We'll have to agree to disagree :-) I think it's useful for some cases. How about this one: You've got an action you want to alias multiple times with different defaults? Jason --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
Re: [OS-webwork] Commands implemented
Jason Carreira wrote: We'll have to agree to disagree :-) I think it's useful for some cases. How about this one: You've got an action you want to alias multiple times with different defaults? If that ever comes up, I'll answer it. So far I've never come across such a situation, for me or anyone else. And I'm sure there's thousands of other hypothetical situations we're not covering either. If you have a a concrete example of where this would occur, bring it on :-) /Rickard --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
RE: [OS-webwork] Commands implemented
Keep up the good work guys. This kind of email explaining a new feature should go almost as is in the doc. Just an idea about the interface to stay or to be removed. Could the interface be changed to contain no method. It becomes just a tagging interface much like java.io.Serializable. Cheers. ___ Francois Beauregard, b.ing. Vice-president Recherche et developpement Pyxis Technologies www.pyxis-tech.com T : (450) 681-9094, poste 102 F : (450) 681-5758 [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jason Carreira Sent: February 27, 2003 2:51 AM To: [EMAIL PROTECTED] Subject: [OS-webwork] Commands implemented I've just checked in the command code to xwork. It allows you to do this: action name=commandTest class=com.opensymphony.xwork.SimpleAction param name=foo123/param result name=error type=chain param name=actionNamebar/param /result interceptor-ref name=static-params/ command name=myCommand method=commandMethod param name=bar456/param result name=success type=chain param name=actionNamefoo/param /result interceptor-ref name=logger/ /command /action The command here creates a new alias in the runtime configuration and inherits properties from the enclosing action. It will also call the supplied method. Actions are not required to supply a method, although they can as well. If no method is supplied for an Action, it defaults to calling action.execute(). For now Actions must still implement this interface, although this can easily be removed and the object can be cast to Action before calling execute(). This should be the last major change to configuration. The only other thing I want to do, and I just thought of this while I was writing this, is to make name optional on the Action and have it not create a runtime ActionConfig for the action itself if there is no name, although you could have several commands underneath the action which would be configured. I also refactored the names of the config classes. Configuration - ConfigurationProvider ConfigurationFactory - ConfigurationProviderFactory DefaultConfiguration - DefaultConfigurationProvider SimpleConfiguration - SimpleConfigurationProvider I've also created 2 new classes in the ActionConfig class hierarchy to support commands: ActionCommand ^ | ActionConfig ^ | HierarchicalActionConfig ActionCommand has: methodName Interceptors Parameters Results resultParameters ActionConfig adds: Class clazz TypeConverter HierarchicalActionConfig adds: Commands ActionConfig is the runtime datastructure, the other 2 are used on the programmatic side. Ok, so go ahead and start making fun of my class naming, but you'd better have some better ideas :-) Jason -- Jason Carreira Technical Architect, Notiva Corp. phone: 585.240.2793 fax: 585.272.8118 email: [EMAIL PROTECTED] --- Notiva - optimizing trade relationships (tm) --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
[OS-webwork] Commands implemented
I've just checked in the command code to xwork. It allows you to do this: action name=commandTest class=com.opensymphony.xwork.SimpleAction param name=foo123/param result name=error type=chain param name=actionNamebar/param /result interceptor-ref name=static-params/ command name=myCommand method=commandMethod param name=bar456/param result name=success type=chain param name=actionNamefoo/param /result interceptor-ref name=logger/ /command /action The command here creates a new alias in the runtime configuration and inherits properties from the enclosing action. It will also call the supplied method. Actions are not required to supply a method, although they can as well. If no method is supplied for an Action, it defaults to calling action.execute(). For now Actions must still implement this interface, although this can easily be removed and the object can be cast to Action before calling execute(). This should be the last major change to configuration. The only other thing I want to do, and I just thought of this while I was writing this, is to make name optional on the Action and have it not create a runtime ActionConfig for the action itself if there is no name, although you could have several commands underneath the action which would be configured. I also refactored the names of the config classes. Configuration - ConfigurationProvider ConfigurationFactory - ConfigurationProviderFactory DefaultConfiguration - DefaultConfigurationProvider SimpleConfiguration - SimpleConfigurationProvider I've also created 2 new classes in the ActionConfig class hierarchy to support commands: ActionCommand ^ | ActionConfig ^ | HierarchicalActionConfig ActionCommand has: methodName Interceptors Parameters Results resultParameters ActionConfig adds: Class clazz TypeConverter HierarchicalActionConfig adds: Commands ActionConfig is the runtime datastructure, the other 2 are used on the programmatic side. Ok, so go ahead and start making fun of my class naming, but you'd better have some better ideas :-) Jason -- Jason Carreira Technical Architect, Notiva Corp. phone: 585.240.2793 fax: 585.272.8118 email: [EMAIL PROTECTED] --- Notiva - optimizing trade relationships (tm) --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
