Re: Simplifying DynaActionForms
Craig R. McClanahan wrote: Also, if we were to add getString() and getBoolean(), we should also add setString() and setBoolean() for the same reasons. Hey, I know this is an old conversation, but I just realized String[] getStringArray() and void setStringArray(String[] array) might be nice too, since multiselects are used fairly often in some applications (OK, in my application) Craig Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Simplifying DynaActionForms
--- Sgarlata Matt [EMAIL PROTECTED] wrote: Craig R. McClanahan wrote: Also, if we were to add getString() and getBoolean(), we should also add setString() and setBoolean() for the same reasons. Hey, I know this is an old conversation, but I just realized String[] getStringArray() and void setStringArray(String[] array) might be nice too, since multiselects are used fairly often in some applications (OK, in my application) I recently added getString() and getStrings() to DynaActionForm. getStrings() returns a String[]. I don't think we need a setString() method because the set() methods take Object as the value (which obviously could be a String). David Craig Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Flexible form support (was Re: Simplifying DynaActionForms)
Steve Raeburn wrote: The problem with adding a 'parameter' is that you then find a need for another parameter, etc etc. Is set-property not suitable here? Or, even better, nested configuration elements under form-bean. Yes, set-property would work here, just like everywhere else. I'm just saying that if action has a general-purpose parameter, then maybe form-bean and forward should have one too. People would not then have to extend action-forward or form-bean every time they wanted to try something out. IMHO, the general purpose parameter has been a useful feature of ActionConfig/ActionMapping and is worth applying elsewhere. We just have to be quick to remind people that if they outgrow the general purpose parameter, then they should start extending the base object and using set-property. (As people often do now.) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Simplifying DynaActionForms
In terms of simplifying the maintenance of DynaActionForms, I was wondering if we had tried anything like this yet? form-bean name=inputBean type=org.apache.struts.validator.DynaValidatorForm proxy=com.mycompany.project.businessBean / where the proxy class would be introspected, and String or boolean dynaproperties generated for each public property? (Rather than specify them ourselves as XML.) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Flexible form support (was Re: Simplifying DynaActionForms)
This reminds me, I think Struts should be more flexible supporting the configuration of other types of forms or extensions to existing forms (like the aforementioned modification to the dynaform). While you can specify any form class, you cannot pass properties to that instance making it difficult to develop generic, powerful forms, like dynaforms, outside the Struts framework. For example, I've been working with an extension of ActionForm that uses XML as its model, allowing the XML to be modified directly through Struts saving heaps of mapping code. In addition to naming my class, I'd like to specify the XML file it should use as a model. Currently, I do this although it is admittedly a hack: form-bean name=UserForm type=com.oroad.stxx.xform.DOMForm form-property name=xml type=/WEB-INF/models/user.xml /form-bean In addition, in order to have control over the form population, I have to extend RequestProcessor and override processPopulate(). Therefore, I think there should be a way to: 1. Pass parameters to a form in the configuration 2. Explicitly handle form population. Perhaps there are strong reasons why this wouldn't be a good idea, but I'd like to hear them. I apologize if this topic has already been dealt with. Don On Fri, 15 Aug 2003, Ted Husted wrote: In terms of simplifying the maintenance of DynaActionForms, I was wondering if we had tried anything like this yet? form-bean name=inputBean type=org.apache.struts.validator.DynaValidatorForm proxy=com.mycompany.project.businessBean / where the proxy class would be introspected, and String or boolean dynaproperties generated for each public property? (Rather than specify them ourselves as XML.) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Flexible form support (was Re: Simplifying DynaActionForms)
Don Brown wrote: 2. Explicitly handle form population. I've never been quite sure whether it should be the RequestProcessor's job to populate an ActionForm, or whether a ActionForm should populate itself. The reset() method is essentially a pre-population extension point, and validate is essentially a post-population extension point, but there is no populate extension point ~:) 1. Pass parameters to a form in the configuration You might want to extend form-bean and put your parameter there. You'd then look up the form-bean through the ActionMapping to retrieve it. One suggestion might be to add a standard parameter properties to form-bean and action-forward, for the same reasons we have the parameter property on action-mapping. You could then just say form-bean name=UserForm type=com.oroad.stxx.xform.DOMForm parameter=/WEB-INF/models/user.xml/ And if there were a ActionForm populate method (instead of a processPopulate method), you can have your DOMForm grab the parameter from the ActionMapping, and do whatever it needs to do to itself. Likewise, the form-bean might give us a place to retrofit a populate method (assuming we decided that we wanted one). There could be a processPopulate property on the form-bean, and if set to false, the RequestProcessor could call form.populate(mapping,request) instead of performing its own behavior. -Ted. Don Brown wrote: This reminds me, I think Struts should be more flexible supporting the configuration of other types of forms or extensions to existing forms (like the aforementioned modification to the dynaform). While you can specify any form class, you cannot pass properties to that instance making it difficult to develop generic, powerful forms, like dynaforms, outside the Struts framework. For example, I've been working with an extension of ActionForm that uses XML as its model, allowing the XML to be modified directly through Struts saving heaps of mapping code. In addition to naming my class, I'd like to specify the XML file it should use as a model. Currently, I do this although it is admittedly a hack: form-bean name=UserForm type=com.oroad.stxx.xform.DOMForm form-property name=xml type=/WEB-INF/models/user.xml /form-bean In addition, in order to have control over the form population, I have to extend RequestProcessor and override processPopulate(). Therefore, I think there should be a way to: 1. Pass parameters to a form in the configuration 2. Explicitly handle form population. Perhaps there are strong reasons why this wouldn't be a good idea, but I'd like to hear them. I apologize if this topic has already been dealt with. Don On Fri, 15 Aug 2003, Ted Husted wrote: In terms of simplifying the maintenance of DynaActionForms, I was wondering if we had tried anything like this yet? form-bean name=inputBean type=org.apache.struts.validator.DynaValidatorForm proxy=com.mycompany.project.businessBean / where the proxy class would be introspected, and String or boolean dynaproperties generated for each public property? (Rather than specify them ourselves as XML.) -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ted Husted, Junit in Action - http://www.manning.com/massol/, Struts in Action - http://husted.com/struts/book.html, JSP Site Design - http://www.amazon.com/exec/obidos/ISBN=1861005512. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Flexible form support (was Re: Simplifying DynaActionForms)
-Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: August 15, 2003 5:55 PM To: Struts Developers List Subject: Re: Flexible form support (was Re: Simplifying DynaActionForms) ... One suggestion might be to add a standard parameter properties to form-bean and action-forward, for the same reasons we have the parameter property on action-mapping. You could then just say form-bean name=UserForm type=com.oroad.stxx.xform.DOMForm parameter=/WEB-INF/models/user.xml/ ... The problem with adding a 'parameter' is that you then find a need for another parameter, etc etc. Is set-property not suitable here? Or, even better, nested configuration elements under form-bean. Steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Simplifying DynaActionForms
--- Sgarlata Matt [EMAIL PROTECTED] wrote: Casting to String gets to be quite painful with many form properties. Unless I've forgotten/missed an easier way of dealing with DynaActionForms, I propose we add a DynaActionForm.getAsString(String) method that does this casting for us. This is a minor point, but how about DynaActionForm.getString(String) instead? I like your name better :-). This would be consistent with naming conventions in java.sql.ResultSet (I can't think of other places with convenience methods like this off the top of my head). Also, following along in the java.sql.ResultSet thinking, would you also have getters for the other wrappers around primitives and the Date and Calendar objects? This might just clutter the interface... I wouldn't ever personally use them in my app because almost every form property is a String. Well, I thought we could start small with the String and take it from there. My form properties are all Strings so that's why my suggestion was aimed in that direction. David Matt Thoughts? David __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Simplifying DynaActionForms
It is such a small change, and you have done so much for the community, I imagine that you should do as you would like. .V David Graham wrote: Here's a snippet from my typical Action.execute() that deals with DynaActionForms: DynaActionForm dynaForm = (DynaActionForm)form; String userName = (String) dynaForm.get(userName); // do something with userName... Casting to String gets to be quite painful with many form properties. Unless I've forgotten/missed an easier way of dealing with DynaActionForms, I propose we add a DynaActionForm.getAsString(String) method that does this casting for us. Thoughts? David __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Simplifying DynaActionForms
Casting to String gets to be quite painful with many form properties. Unless I've forgotten/missed an easier way of dealing with DynaActionForms, I propose we add a DynaActionForm.getAsString(String) method that does this casting for us. This is a minor point, but how about DynaActionForm.getString(String) instead? This would be consistent with naming conventions in java.sql.ResultSet (I can't think of other places with convenience methods like this off the top of my head). Also, following along in the java.sql.ResultSet thinking, would you also have getters for the other wrappers around primitives and the Date and Calendar objects? This might just clutter the interface... I wouldn't ever personally use them in my app because almost every form property is a String. Matt Thoughts? David __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Simplifying DynaActionForms
--- Kris Schneider [EMAIL PROTECTED] wrote: String value = BeanUtils.getProperty(form, propName); No casting and it works for *any* form, meaning that your Action code is independent of your choice of form implementation (vanilla or dyna). Good point but I think it's still a bit verbose for certain use cases. dynaForm.getString(propName) is tidier and allows for easier to read nested calls like this: service.doSomeService(dynaForm.getString(propName)) instead of: service.doSomeService(BeanUtils.getProperty(form, propName)) which could get quite long if you're passing several properties. David So, FWIW, even if you added the method, I personally wouldn't use it. I even find using PropertyUtils preferable: String value = (String)PropertyUtils.getProperty(form, propName); It's more important to me to abstract the type of the form than the type of the property. Quoting Sgarlata Matt [EMAIL PROTECTED]: Casting to String gets to be quite painful with many form properties. Unless I've forgotten/missed an easier way of dealing with DynaActionForms, I propose we add a DynaActionForm.getAsString(String) method that does this casting for us. This is a minor point, but how about DynaActionForm.getString(String) instead? This would be consistent with naming conventions in java.sql.ResultSet (I can't think of other places with convenience methods like this off the top of my head). Also, following along in the java.sql.ResultSet thinking, would you also have getters for the other wrappers around primitives and the Date and Calendar objects? This might just clutter the interface... I wouldn't ever personally use them in my app because almost every form property is a String. Matt Thoughts? David -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Simplifying DynaActionForms
String value = BeanUtils.getProperty(form, propName); No casting and it works for *any* form, meaning that your Action code is independent of your choice of form implementation (vanilla or dyna). So, FWIW, even if you added the method, I personally wouldn't use it. I even find using PropertyUtils preferable: String value = (String)PropertyUtils.getProperty(form, propName); It's more important to me to abstract the type of the form than the type of the property. Quoting Sgarlata Matt [EMAIL PROTECTED]: Casting to String gets to be quite painful with many form properties. Unless I've forgotten/missed an easier way of dealing with DynaActionForms, I propose we add a DynaActionForm.getAsString(String) method that does this casting for us. This is a minor point, but how about DynaActionForm.getString(String) instead? This would be consistent with naming conventions in java.sql.ResultSet (I can't think of other places with convenience methods like this off the top of my head). Also, following along in the java.sql.ResultSet thinking, would you also have getters for the other wrappers around primitives and the Date and Calendar objects? This might just clutter the interface... I wouldn't ever personally use them in my app because almost every form property is a String. Matt Thoughts? David -- Kris Schneider mailto:[EMAIL PROTECTED] D.O.Tech http://www.dotech.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Simplifying DynaActionForms
On Wed, 13 Aug 2003, David Graham wrote: Date: Wed, 13 Aug 2003 20:01:59 -0700 (PDT) From: David Graham [EMAIL PROTECTED] Reply-To: Struts Developers List [EMAIL PROTECTED], [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Subject: Re: Simplifying DynaActionForms --- Sgarlata Matt [EMAIL PROTECTED] wrote: Casting to String gets to be quite painful with many form properties. Unless I've forgotten/missed an easier way of dealing with DynaActionForms, I propose we add a DynaActionForm.getAsString(String) method that does this casting for us. This is a minor point, but how about DynaActionForm.getString(String) instead? I like your name better :-). This would be consistent with naming conventions in java.sql.ResultSet (I can't think of other places with convenience methods like this off the top of my head). Also, following along in the java.sql.ResultSet thinking, would you also have getters for the other wrappers around primitives and the Date and Calendar objects? This might just clutter the interface... I wouldn't ever personally use them in my app because almost every form property is a String. Well, I thought we could start small with the String and take it from there. My form properties are all Strings so that's why my suggestion was aimed in that direction. If we go for this idea on DynaActionForm (I'm +0 on it at the moment), we should provide accessors for String and boolean properties, but I'd suggest we don't for any other types -- after all, Struts encourages you not to use things like Date or Calendar for a form bean property :-). Note that I'd be -1 on doing this sort of thing to the underlying DynaBean interface itself. Besides the fact that this would break current implementations (since DynaBean is an interface), I don't want to see a very simple API like DynaBean turn into a mass of methods like ResultSet. Also, if we were to add getString() and getBoolean(), we should also add setString() and setBoolean() for the same reasons. David Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Simplifying DynaActionForms
Here's a snippet from my typical Action.execute() that deals with DynaActionForms: DynaActionForm dynaForm = (DynaActionForm)form; String userName = (String) dynaForm.get(userName); // do something with userName... Casting to String gets to be quite painful with many form properties. Unless I've forgotten/missed an easier way of dealing with DynaActionForms, I propose we add a DynaActionForm.getAsString(String) method that does this casting for us. Thoughts? David __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
