Re: [OS-webwork] Action configuration XML [Commands]
Chris Nokleberg wrote: I don't understand this logic. A property default is a default for form parameters, obviously it can change. If you want to fix the value for a particular mapping, you add it to actions.xml. Not quite. In an action there are two sets of parameters: initialization parameters and form parameters. From an action point of view they are equivalent however, since both are set through set* methods. If both are set the same way then there is a potential security problem if a user sets an init parameter through a form submission. I.e. a parameter which was supposed to be set through some initialization parameter is instead provided by the user. The way to get around that is to: 1) Set form parameters first and init parameters later. However, this makes it impossible to use the init parameters during the prepare() step, which is where they would be perhaps most useful. 2) Require that all init parameters are set in xwork.xml. Even if the default is ok, the value must be provided again, or else there is a security hole. Both of these two issues go away if init-parameters are provided through the context, or similar, i.e. not by calling set* methods in the action. The argument that it will hurt performance is really misleading IMHO. You're assuming a certain implementation. Sure, I'm assuming reflection. Is there any other way to do it? For one thing, since the parameters and values and destination classes are known ahead of time, you can pre-convert all of the values. etc., etc. That's certainly possible, and would remove some of the overhead. The other issues still remain. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- 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] Action configuration XML [Commands]
Heng Sin Low wrote: May be don't use reflection then and delegate this to the action itself. For e.g, this can be implemented by adding an init method to the Action interface that take a map as parameter. This would also allow us to differentiate between init parameter ( usually for configuration purpose ) and runtime parameter ( usually use input ). That would work just fine. You could do this in the prepare() step. Making a baseclass that has an implementation that does BeanUtil.copy(Map, this); would do the trick. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- 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] Action configuration XML [Commands]
On Thu, Jan 02, 2003 at 09:23:19PM +0100, Rickard Öberg wrote: Chris Nokleberg wrote: There are some interesting questions regarding the ordering of all the parameter setting, though. I'd prefer that the action properties overwrite any form parameters. If you're using the properties to parameterize the execution of the action from your config file, you don't want the user to be able to mess with things just by guessing the right property name. But that can break too, if you're using defaulted values. Let's say you have a property that can be set called foo and that default is 5. If you're happy with that then you do nothing in the XML descriptor, and thus expect 5 to be the value. Then a user could override it using a parameter. I don't understand this logic. A property default is a default for form parameters, obviously it can change. If you want to fix the value for a particular mapping, you add it to actions.xml. The argument that it will hurt performance is really misleading IMHO. You're assuming a certain implementation. For one thing, since the parameters and values and destination classes are known ahead of time, you can pre-convert all of the values. etc., etc. -Chris --- 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
[OS-webwork] Action configuration XML
I'm fiddling with the action configuration XML, and here's what I have currently. xwork package name=standard prefixes=com.opensymphony.xwork interceptor name=parameter class=action.interceptor.ParameterInterceptor/ interceptors name=default interceptor-ref name=parameter/ /interceptors result name=error view=error.jsp/ /package package name=examples depends=standard prefixes=com.opensymphony.xwork.action result name=error view=exampleerror.jsp/ action name=foo class=SimpleAction interceptors-ref name=default/ result name=success view=bar.action/ /action action name=Bar class=SimpleAction interceptors-ref name=default/ result name=success view=success.jsp/ /action /package package name=examples2 depends=standard prefixes=com.opensymphony.xwork.action action name=foo class=SimpleAction interceptors-ref name=default/ result name=success view=bar.action/ /action action name=Bar class=SimpleAction interceptors-ref name=default/ result name=success view=success.jsp/ /action /package /xwork -- There are a couple of core ideas here. The first is the introduction of packages. This allows a single XML file to be built up of many individually developed packages. Typically one would use XML entities to refer to them, so the base XML file would typically look like this: xwork standard; examples; examples2; /xwork where those entities refer to the individual package files. It might even be a good idea to use a default entity resolver which understands .xml suffixes so one doesn't have to declare those entities: xwork standard.xml; examples.xml; examples2.xml; /xwork and here it would also be possible to add a standard entity resolver that understands properties files: xwork standard.xml; examples.xml; examples2.properties; /xwork so that simple packages can be defined using the old format. By using XML entities one can easily put several independent packages together into one coherent application. The next highlight is the notion of package specific prefixes. Pretty obvious what they're for I hope. Next up is the depends attribute, which is used to declare what packages it builds on, and this is mainly in order to do interceptor referencing. There will usually be a standard package with common interceptors and interceptor stacks (as shown above), and these can then be referenced easily, and application-specific interceptors can be introduced in ones own package. One can even override stacks and interceptors this way: package name=examples depends=standard prefixes=com.opensymphony.xwork.action interceptor name=mystuff class=MyInterceptor/ interceptors name=default interceptor-ref name=mystuff/ interceptors-ref name=default/ /interceptors action name=foo class=SimpleAction interceptors-ref name=default/ result name=success view=bar.action/ /action /package --- The above would override the default interceptor stack from the inherited package. We then come to the definition of a single action: action name=foo class=SimpleAction interceptors-ref name=default/ result name=success view=bar.action/ /action --- The big new thing is the reference to interceptors. Here one typically does two things: refer to a standard stack of interceptors, and then add action-specific interceptors that typically only apply to that single action. This can replace action chaining to a large extent I think. The result declaration is fairly simple, and is just a mapping from the string to the resulting view. .action is used to trigger chaining, to the extent that it's still needed. Default mappings can be declared at the package level (see error declarations above), and also follow the package dependency in order to allow overrides. The main idea with packages is hence to both allow for generic behaviour to be easily utilized, as well as allowing it to be overriden where necessary, while maintaining a fairly strict semantics. Or that's the idea anyway :-) When it comes to action referencing I haven't made up my mind yet what is best, but I think it's necessary to use the package name as prefix, unless an action references another action in the same package. E.g. if the foo action in examples wants to chain to bar in examples2 it would use the name examples2.bar instead of just bar. What is missing from this example currently is commands. Any ideas are welcome here. One option is to have the action declaration look like this: action name=fooDefault class=SimpleAction.doDefault interceptors-ref name=default/ result name=success view=bar.action/ /action i.e. suffix the class name with the method name. This means that any public method with a string result (or even void, which would default the result to SUCCESS) can be
Re: [OS-webwork] Action configuration XML
Copmments: - interceptor-ref name= is ugly XML! Why not just interceptor ref= / ? It's obvious that the name= attribute refers to the name of an interceptor from the tag name - is there a global package? - how are parameterised actions handled? (one of the other main xwork goals?) Looks good otherwise. -mike On 2/1/03 10:18 PM, Rickard Öberg ([EMAIL PROTECTED]) penned the words: I'm fiddling with the action configuration XML, and here's what I have currently. xwork package name=standard prefixes=com.opensymphony.xwork interceptor name=parameter class=action.interceptor.ParameterInterceptor/ interceptors name=default interceptor-ref name=parameter/ /interceptors result name=error view=error.jsp/ /package package name=examples depends=standard prefixes=com.opensymphony.xwork.action result name=error view=exampleerror.jsp/ action name=foo class=SimpleAction interceptors-ref name=default/ result name=success view=bar.action/ /action action name=Bar class=SimpleAction interceptors-ref name=default/ result name=success view=success.jsp/ /action /package package name=examples2 depends=standard prefixes=com.opensymphony.xwork.action action name=foo class=SimpleAction interceptors-ref name=default/ result name=success view=bar.action/ /action action name=Bar class=SimpleAction interceptors-ref name=default/ result name=success view=success.jsp/ /action /package /xwork -- There are a couple of core ideas here. The first is the introduction of packages. This allows a single XML file to be built up of many individually developed packages. Typically one would use XML entities to refer to them, so the base XML file would typically look like this: xwork standard; examples; examples2; /xwork where those entities refer to the individual package files. It might even be a good idea to use a default entity resolver which understands .xml suffixes so one doesn't have to declare those entities: xwork standard.xml; examples.xml; examples2.xml; /xwork and here it would also be possible to add a standard entity resolver that understands properties files: xwork standard.xml; examples.xml; examples2.properties; /xwork so that simple packages can be defined using the old format. By using XML entities one can easily put several independent packages together into one coherent application. The next highlight is the notion of package specific prefixes. Pretty obvious what they're for I hope. Next up is the depends attribute, which is used to declare what packages it builds on, and this is mainly in order to do interceptor referencing. There will usually be a standard package with common interceptors and interceptor stacks (as shown above), and these can then be referenced easily, and application-specific interceptors can be introduced in ones own package. One can even override stacks and interceptors this way: package name=examples depends=standard prefixes=com.opensymphony.xwork.action interceptor name=mystuff class=MyInterceptor/ interceptors name=default interceptor-ref name=mystuff/ interceptors-ref name=default/ /interceptors action name=foo class=SimpleAction interceptors-ref name=default/ result name=success view=bar.action/ /action /package --- The above would override the default interceptor stack from the inherited package. We then come to the definition of a single action: action name=foo class=SimpleAction interceptors-ref name=default/ result name=success view=bar.action/ /action --- The big new thing is the reference to interceptors. Here one typically does two things: refer to a standard stack of interceptors, and then add action-specific interceptors that typically only apply to that single action. This can replace action chaining to a large extent I think. The result declaration is fairly simple, and is just a mapping from the string to the resulting view. .action is used to trigger chaining, to the extent that it's still needed. Default mappings can be declared at the package level (see error declarations above), and also follow the package dependency in order to allow overrides. The main idea with packages is hence to both allow for generic behaviour to be easily utilized, as well as allowing it to be overriden where necessary, while maintaining a fairly strict semantics. Or that's the idea anyway :-) When it comes to action referencing I haven't made up my mind yet what is best, but I think it's necessary to use the package name as prefix, unless an action references another action in the same package. E.g. if the foo action in examples wants to chain to bar in examples2 it would use the name examples2.bar instead of just bar. What is missing from
Re: [OS-webwork] Action configuration XML
Mike Cannon-Brookes wrote: Copmments: - interceptor-ref name= is ugly XML! Why not just interceptor ref= / ? It's obvious that the name= attribute refers to the name of an interceptor from the tag name Because you'd then mix referring to an interceptor and defining one. Take a look again. If you can think of a better name I'm all for it, but there do need to be two. - is there a global package? No, that's why there's the depends thing, which usually includes standard which in a sense is the global package. - how are parameterised actions handled? (one of the other main xwork goals?) I didn't know that was a goal. The implementation that is currently in CVS sets these parameters on each request, which is a lot of reflection. It seemed too heavy to me. Isn't it better to have configuration be handled in a traditional way? (i.e. by calling some config API) Remember that actions are going to be instantiated ALL THE TIME. Using the Preferences API might be an option here. /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] Action configuration XML
Great, I like this interceptor stuff, looks cool. Have a couple of doubt though: 1. Can the interceptor affect the view mapping in anyway ? 2. How about providing different view base on client device. For e.g, providing different view for html, xml, wml, xul, etc. 3. Can a package depends on more than one package ? 4. I don't really understand why the interceptor stack ( the interceptors tag ) is nested inside the package tag. It seems like the idea is we can construct an interceptor stack from multiple package. 5. May be there should be a packages tag so that we can package multiple dependent package together. 6. It seems like there could be many place that we can have name collision issue. Not sure whether this is a major issue, may be we need some namespace mechanism here. 7. Would like to see some sort of mechanism to pass some initialization parameter to the action. ( like the init param thing in servlet configuration ) 8. Is there anything in the config that would define the scope of the interceptor ( for e.g, pre/post action execution, pre/post entire action chain execution, etc ) ? Btw, just curious if u already using an AOP framework, wouldn't all this webwork-interceptor stuff redundant for u ? Regards, Low --- Rickard Öberg [EMAIL PROTECTED] wrote: I'm fiddling with the action configuration XML, and here's what I have currently. xwork package name=standard prefixes=com.opensymphony.xwork interceptor name=parameter class=action.interceptor.ParameterInterceptor/ interceptors name=default interceptor-ref name=parameter/ /interceptors result name=error view=error.jsp/ /package package name=examples depends=standard prefixes=com.opensymphony.xwork.action result name=error view=exampleerror.jsp/ action name=foo class=SimpleAction interceptors-ref name=default/ result name=success view=bar.action/ /action action name=Bar class=SimpleAction interceptors-ref name=default/ result name=success view=success.jsp/ /action /package package name=examples2 depends=standard prefixes=com.opensymphony.xwork.action action name=foo class=SimpleAction interceptors-ref name=default/ result name=success view=bar.action/ /action action name=Bar class=SimpleAction interceptors-ref name=default/ result name=success view=success.jsp/ /action /package /xwork -- There are a couple of core ideas here. The first is the introduction of packages. This allows a single XML file to be built up of many individually developed packages. Typically one would use XML entities to refer to them, so the base XML file would typically look like this: xwork standard; examples; examples2; /xwork where those entities refer to the individual package files. It might even be a good idea to use a default entity resolver which understands .xml suffixes so one doesn't have to declare those entities: xwork standard.xml; examples.xml; examples2.xml; /xwork and here it would also be possible to add a standard entity resolver that understands properties files: xwork standard.xml; examples.xml; examples2.properties; /xwork so that simple packages can be defined using the old format. By using XML entities one can easily put several independent packages together into one coherent application. The next highlight is the notion of package specific prefixes. Pretty obvious what they're for I hope. Next up is the depends attribute, which is used to declare what packages it builds on, and this is mainly in order to do interceptor referencing. There will usually be a standard package with common interceptors and interceptor stacks (as shown above), and these can then be referenced easily, and application-specific interceptors can be introduced in ones own package. One can even override stacks and interceptors this way: package name=examples depends=standard prefixes=com.opensymphony.xwork.action interceptor name=mystuff class=MyInterceptor/ interceptors name=default interceptor-ref name=mystuff/ interceptors-ref name=default/ /interceptors action name=foo class=SimpleAction interceptors-ref name=default/ result name=success view=bar.action/ /action /package --- The above would override the default interceptor stack from the inherited package. We then come to the definition of a single action: action name=foo class=SimpleAction interceptors-ref name=default/ result name=success view=bar.action/ /action --- The big new thing is the reference to interceptors. Here one typically does two things: refer to a standard stack of interceptors, and then add action-specific interceptors that typically only
RE: [OS-webwork] Action configuration XML [Commands]
Couldn't the Method objects found the first time through reflection for parameterizing the Action instances be cached and reused, making the reflection performance hit negligible? I've never profiled reflection to see where the biggest performance hit is, but if it's the Class and Method lookup, this could help (and be used for the Action field population, as well) -Original Message- From: Patrick Lightbody [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 02, 2003 11:59 AM To: [EMAIL PROTECTED] Subject: Re: [OS-webwork] Action configuration XML [Commands] What is missing from this example currently is commands. Any ideas are welcome here. One option is to have the action declaration look like this: action name=fooDefault class=SimpleAction.doDefault interceptors-ref name=default/ result name=success view=bar.action/ /action i.e. suffix the class name with the method name. This means that any public method with a string result (or even void, which would default the result to SUCCESS) can be invoked. Any comments on this? I think that the ability to have parameters applied before the action is initialized is a feature needed, even if it could be slow. For the most part there will be zero params, so the slowdown isn't an issue. Commands, in my opinion, should not be part of the configuration if they aren't part of the core framework -- meaning that since ActionSupport deals with commands but Action is the only core part of the framework, commands don't deserve special treament. That was where I got the idea for having parameters that would be applied before the Action is executed. So with that said, I think commands should be configured like so: action name=fooDefault class=SimpleActiont interceptors-ref name=default/ result name=success view=bar.action/ params param name=commanddefault/param /params /action The end result is the same (since commands needed reflection anyway). The only difference is that there is an option for even more flexability, but no one has to use it if they are worried about reflection (though since every single HTTP request parameter is also reflected, I see no big problem by adding this as well). -Pat --- 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 --- 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] Action configuration XML [Commands]
What is missing from this example currently is commands. Any ideas are welcome here. One option is to have the action declaration look like this: action name=fooDefault class=SimpleAction.doDefault interceptors-ref name=default/ result name=success view=bar.action/ /action i.e. suffix the class name with the method name. This means that any public method with a string result (or even void, which would default the result to SUCCESS) can be invoked. Any comments on this? I think that the ability to have parameters applied before the action is initialized is a feature needed, even if it could be slow. For the most part there will be zero params, so the slowdown isn't an issue. Commands, in my opinion, should not be part of the configuration if they aren't part of the core framework -- meaning that since ActionSupport deals with commands but Action is the only core part of the framework, commands don't deserve special treament. That was where I got the idea for having parameters that would be applied before the Action is executed. So with that said, I think commands should be configured like so: action name=fooDefault class=SimpleActiont interceptors-ref name=default/ result name=success view=bar.action/ params param name=commanddefault/param /params /action The end result is the same (since commands needed reflection anyway). The only difference is that there is an option for even more flexability, but no one has to use it if they are worried about reflection (though since every single HTTP request parameter is also reflected, I see no big problem by adding this as well). -Pat --- 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] Action configuration XML [Commands]
See, I just think it's invaluable for action re-use to be able to lock down certain parameters for various aliases, even if the action classs is the same. For example: In my document/workflow management system, we have various businessgroups that can create documents. Ideally, there could be a FooCreateDocument and BarCreateDocument action aliasing, both maping to com.cisco.CreateDocument. The only different would be that each alias would have a different value for the businessGroup parameter (one has Foo, one has Bar). Yes, this could be done with CreateDocument.action?businessGroup=Foo, but then the burdon is on the HTML/JSP writers and not the application designer. -Pat - Original Message - From: Rickard Öberg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 02, 2003 9:41 AM Subject: Re: [OS-webwork] Action configuration XML [Commands] Patrick Lightbody wrote: I think that the ability to have parameters applied before the action is initialized is a feature needed, even if it could be slow. For the most part there will be zero params, so the slowdown isn't an issue. But it's a dangerous option, since it may not be apparent that this slowdown will occur. If possible, configuration of actions should not occur this way. Commands, in my opinion, should not be part of the configuration if they aren't part of the core framework -- meaning that since ActionSupport deals with commands but Action is the only core part of the framework, commands don't deserve special treament. Well, I wanted to see if commands maybe could be put in as a core concept. That was where I got the idea for having parameters that would be applied before the Action is executed. So with that said, I think commands should be configured like so: action name=fooDefault class=SimpleActiont interceptors-ref name=default/ result name=success view=bar.action/ params param name=commanddefault/param /params /action The end result is the same (since commands needed reflection anyway). No, you now have two reflective calls: the parameter and the execution. If this is the only reason to use parameters, the case is a bit weak. The only difference is that there is an option for even more flexability, but no one has to use it if they are worried about reflection (though since every single HTTP request parameter is also reflected, I see no big problem by adding this as well). I think having an option which will lead to foot-shooting is a bad idea. And I don't think documentation is a solution for that either. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- 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 --- 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] Action configuration XML [Commands]
boxed wrote: I think having an option which will lead to foot-shooting is a bad idea. And I don't think documentation is a solution for that either. Correct me if I'm wrong, but didn't pat just suggest that you should be able to set default parameters on actions in the config file. I don't see how this can be a foot-shooting idea at all, but I do see it simplifying development. I just wish taglib definitions had this feature... If you read the whole email you'd know why. Let me quote: But it's a dangerous option, since it may not be apparent that this slowdown will occur. If possible, configuration of actions should not occur this way. /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] Action configuration XML [Commands]
Jason Carreira wrote: Couldn't the Method objects found the first time through reflection for parameterizing the Action instances be cached and reused, making the reflection performance hit negligible? I've never profiled reflection to see where the biggest performance hit is, but if it's the Class and Method lookup, this could help (and be used for the Action field population, as well) The biggest hit is in lookup, absolutely. However, there's overhead for type conversion too. And if you compare it with a simple Conf.getValue() call the overhead is MUCH higher. /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] Action configuration XML [Commands]
On Thu, Jan 02, 2003 at 06:41:59PM +0100, Rickard Öberg wrote: Patrick Lightbody wrote: I think that the ability to have parameters applied before the action is initialized is a feature needed, even if it could be slow. For the most part there will be zero params, so the slowdown isn't an issue. But it's a dangerous option, since it may not be apparent that this slowdown will occur. If possible, configuration of actions should not occur this way. I think it is a very useful feature, and this is to me this is an obvious case premature optimization. I should mention that I'm a developer at cglib.sf.net, and one of the things on my TODO list is write a bcel-ified bean copier. Webwork would benefit greatly from this, since the configuration is (totally?) static, which means the same beans are copied over and over again. The end result is that the overhead of having action properties work bean-style would probably be negligible, and for sure faster than using the Preferences API in execute(). -Chris --- 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] Action configuration XML [Commands]
So then how would the situation outlined below work then? I understand the deployment-settings vs. business login parameter issue, but where would those kinds of parameters be set? I don't think in the HTML URL would be a good idea. I like being able to make two different alias names that are similar (same class) but behave differently based on settings. -Pat - Original Message - From: Rickard Ã-berg [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 02, 2003 10:30 AM Subject: Re: [OS-webwork] Action configuration XML [Commands] Patrick Lightbody wrote: See, I just think it's invaluable for action re-use to be able to lock down certain parameters for various aliases, even if the action classs is the same. For example: In my document/workflow management system, we have various businessgroups that can create documents. Ideally, there could be a FooCreateDocument and BarCreateDocument action aliasing, both maping to com.cisco.CreateDocument. The only different would be that each alias would have a different value for the businessGroup parameter (one has Foo, one has Bar). Yes, this could be done with CreateDocument.action?businessGroup=Foo, but then the burdon is on the HTML/JSP writers and not the application designer. Hm.. but that doesn't sound like an application deployment setting (which action parameterizing would be). Sounds more like a business logic parameter to me. And if you really want to an action configuration like that, the Preferences API should do the trick. /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 --- 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] Action configuration XML [Commands]
Patrick Lightbody wrote: So then how would the situation outlined below work then? I understand the deployment-settings vs. business login parameter issue, but where would those kinds of parameters be set? I don't think in the HTML URL would be a good idea. I like being able to make two different alias names that are similar (same class) but behave differently based on settings. Ok. Well, if the performance overhead is so negligble as some suggest, then maybe it's ok. Can't say I like it though, for mentioned reasons. Plus, iff it's put into an interceptor then people like me can remove 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] Action configuration XML [Commands]
Bruce Ritchie wrote: The unfortunate part about using the preferences API is that it ties xw to jdk 1.4, which will mean that it excludes many many people from using it (us for example) since many of our customers have and will continue to run jdk 1.3 for some time. I would prefer an alternate system that doesn't tie us to jdk 1.4. I said that you *could* use the Preferences API. If you don't want to, then don't. We deploy our stuff on all platforms on 1.4, so for our needs it's ok. Then again, we probably wouldn't do action-specific configuration anyway, and *if* we did we'd use runtime attributes. But that's a whole other story. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- 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] Action configuration XML [Commands]
Rickard Öberg wrote: I said that you *could* use the Preferences API. If you don't want to, then don't. Fair enough. I just wanted to be clear that I don't want it as a dependency :) Regards, Bruce Ritchie smime.p7s Description: S/MIME Cryptographic Signature
Re: [OS-webwork] Action configuration XML [Commands]
Chris Nokleberg wrote: Oops: this is to me an obvious case of premature optimization. But optimization is a maybe not the best word for omitting a feature completely :-) Right. The idea was to perhaps find a better way to accomplish the same thing. Once a good way has been found, then we can discuss various optimizations of it. I'd like to see properties on results as well as action mappings, which would be applied to the chained action. There are some interesting questions regarding the ordering of all the parameter setting, though. I'd prefer that the action properties overwrite any form parameters. If you're using the properties to parameterize the execution of the action from your config file, you don't want the user to be able to mess with things just by guessing the right property name. But that can break too, if you're using defaulted values. Let's say you have a property that can be set called foo and that default is 5. If you're happy with that then you do nothing in the XML descriptor, and thus expect 5 to be the value. Then a user could override it using a parameter. Another reason why doing action configuration this way is a bad idea in the first place I guess. /Rickard -- Rickard Öberg [EMAIL PROTECTED] Senselogic Got blog? I do. http://dreambean.com --- 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] Action configuration XML [Commands]
If you read the whole email you'd know why. Let me quote: But it's a dangerous option, since it may not be apparent that this slowdown will occur. If possible, configuration of actions should not occur this way. Given the huge amount of reflection in webwork anyway, is a little more going to hurt? (And as someone said - wouldn't it all be cached anyway?) -mike PS I'm +1 for action parameters - v. useful! --- 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] Action configuration XML [Commands]
May be don't use reflection then and delegate this to the action itself. For e.g, this can be implemented by adding an init method to the Action interface that take a map as parameter. This would also allow us to differentiate between init parameter ( usually for configuration purpose ) and runtime parameter ( usually use input ). Regards, Low --- Rickard_Öberg [EMAIL PROTECTED] wrote: Jason Carreira wrote: Couldn't the Method objects found the first time through reflection for parameterizing the Action instances be cached and reused, making the reflection performance hit negligible? I've never profiled reflection to see where the biggest performance hit is, but if it's the Class and Method lookup, this could help (and be used for the Action field population, as well) The biggest hit is in lookup, absolutely. However, there's overhead for type conversion too. And if you compare it with a simple Conf.getValue() call the overhead is MUCH higher. /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 __ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com --- 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
