Re: ActionMapping parameter
I'm not saying it's a bad idea, but be very careful what road you start down. If you're not careful, you end up programming in xml, which can have its down sides - Original Message - From: Ernest Jones [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, September 04, 2001 11:50 AM Subject: ActionMapping parameter I wanted some feedback on a feature request before I submit it. In the ActionMapping api you can only get one nameless config parameter (public String getParameter()). I would find it useful if I could specify any number of named parameters (public String getParameter(String key)). The xml in the struts-config file could look like: action path=/myPath type=com.mycompany.actions.DoSomething parameter name=paramName value=paramValue/ parameter name=paramName2 value=paramValue2/ ... forward name=success path=/success.jsp / /action To maintain backwards compatability (if you really wanted to) you could keep the old parameter attribute and function. Thoughts? Comments?
Re: ActionMapping parameter
Point well taken. The intention is not to pull programming into the configuration file, only to facilitate code re-use. Being able to pass in multiple name value pairs into an action mapping allows the same Action class to be used in different situations, servlet-contexts, etc. One may want to specify database urls, jdbc class-names to use, file locations of resources, messages to log, and who knows what else. Alternative solutions include: 1. Using init-parameters on the ActionServlet drawbacks: --only one configuration possible of an Action per servlet-context --naming conflicts have to be watched for. 2. Using a properties file drawbacks: --if the file location is hard coded, you have the same problem of only one configuration possible of an Action per servlet-context or (to get around that): --if the property file is specified as the parameter value, you still have to maintain x number of different configuration/property files. 3. Using some sort of delimited name, value specification as the parameter value (sort of like cgi query strings) drawbacks: --the struts users have to do all the parameter parsing. --its a more complicated, uglier solution for those writing the config file. Xml provides a much simpler, cleaner solution with child elements. - Original Message - From: David Corbin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, September 04, 2001 11:49 AM Subject: Re: ActionMapping parameter I'm not saying it's a bad idea, but be very careful what road you start down. If you're not careful, you end up programming in xml, which can have its down sides - Original Message - From: Ernest Jones [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Tuesday, September 04, 2001 11:50 AM Subject: ActionMapping parameter I wanted some feedback on a feature request before I submit it. In the ActionMapping api you can only get one nameless config parameter (public String getParameter()). I would find it useful if I could specify any number of named parameters (public String getParameter(String key)). The xml in the struts-config file could look like: action path=/myPath type=com.mycompany.actions.DoSomething parameter name=paramName value=paramValue/ parameter name=paramName2 value=paramValue2/ ... forward name=success path=/success.jsp / /action To maintain backwards compatability (if you really wanted to) you could keep the old parameter attribute and function. Thoughts? Comments?
Re: ActionMapping parameter
So far, on the DEV list, we've had three suggestions about what to do about this: 1. Use named parameters instead of a single parameter (as just mentioned) 2. Use parameter as the name of a property file or other resource where the actual parameters are kept. 3. Add methods to ActionMappings to retrieve parameters as if parameter were a query string. So in the last case, you could set parameter to be something like parameter=form=input+action=update and then retrieve it using methods like String form = mapping.getParameter(form); and still keep String parameter = mapping.getParameter() to retrieve the String as is (or maybe just the first parameter). This has the virtue of being trival to implement, and jives with the way Forwards have to be coded. A quick and easy way to do this starting now, would be to use the HttpUtils class http://java.sun.com/j2ee/tutorial/api/javax/servlet/http/HttpUtils.html and do something like -- HashTable parameters = HttpUtils.parseQueryString(mappings.getParameter()); String form = (String) parameters.get(form); -- Anyone want to give a implementation of doing this within ActionMappings a whirl? I'd be thinking we'd want all the same parameter methods from ServletRequest http://java.sun.com/j2ee/tutorial/api/javax/servlet/ServletRequest.html Another idea would be to just implement getParameterMap() in ActionMappings, since HttpUtils is deprecated in Servlet 2.3 ;-(, and leave it at that. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.com/about/struts/ Ernest Jones wrote: I wanted some feedback on a feature request before I submit it. In the ActionMapping api you can only get one nameless config parameter (public String getParameter()). I would find it useful if I could specify any number of named parameters (public String getParameter(String key)). The xml in the struts-config file could look like: action path=/myPath type=com.mycompany.actions.DoSomething parameter name=paramName value=paramValue/ parameter name=paramName2 value=paramValue2/ ... forward name=success path=/success.jsp / /action To maintain backwards compatability (if you really wanted to) you could keep the old parameter attribute and function. Thoughts? Comments?
Re: ActionMapping parameter
David Corbin wrote: I'm not saying it's a bad idea, but be very careful what road you start down. If you're not careful, you end up programming in xml, which can have its down sides I think we're already doing that ;-) What's happening now is that people are embedding a lot of control-logic into HTML forms in the form of hidden properties and such. With better support for placing multiple parameters into the ActionMapping, some of that won't be necessary, and more of the control-flow programming can be centralized in the configuration file. Personally, I'm thinking that the best way to handle multiple parameters is as parameters, since this corresponds to what we already have to do with global forwards. Otherwise we end up with two ways to do the same thing, all in the same configuration file. Meanwhile, to close the loop, we should also be able to specify the path for an ActionForm with global and local forwards. This would make it possible to softcode all of the system paths and parameters using logical forwards from the configuration file. I'm currently thinking about trying to extend the HTML form tag to allow use of a FORWARD property as an alternative to the current ACTION property. When this property is used, the tag would check the application mappings for the specified logical name and use the mapped URI for the ACTION property. To permit use of local forwards, the tag could also check for an Action Mapping object in the page, request, and session scopes. If found, the instant mapping object could be used to check for a local and global forwarding. If not found, the application mappings are used instead. Again, the benefit of this change are that all URIs can be replaced with logical forwards throughout a Struts application. It also allows the target of a form to be changed at runtime from the Action. This would makes many workflow patterns easier to achieve. -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel +1 716 737-3463 -- http://www.husted.com/about/struts/