Re: Why do ActionForms allow non-string properties?
we'd be down to a single XML to define the form, the input properties, and their validators. +1 .V Ted Husted wrote: Steve Raeburn wrote: *BUT* there should be a bloody big health warning on the ActionForm documentation that says only ever use Strings! Whether or not to only use Strings only matters if you care about capturing non-string input in a non-string field. Craig always felt that this use-case is very important, and many people agree. In practice, though, sometimes it doesn't matter. If they put AZ1234 in a field, the BeanUtils can quietly convert that to either null or zero. If the field is required, then they can be required to put in a valid, non-zero entry into it. For some clients, this is acceptable. As a consequence, if you have perfectly good business interface that you can otherwise apply to a ActionForm -- there you go, one less JavaBean protocol to maintain (at client's expense). Many people never even realize that there is any type of restriction here. A lot of application only use Strings to begin with. Or, the numbers are input through controls that put the numbers in for people. Or, the application requires clients to use JavaScript and a runtime Javascript keeps the focus on the field until they enter a valid number. I'm using some non-string ActionForm properties in my current application, and it's working just fine. We have exactly two fields that need actual numbers, and they are even required fields. For extra credit, I may try and snag invalid input and see if I can pump it into a validation message (AZ1234 is not a valid number). (Which, IMHO, is more appropriate than repopulating a field with invalid input.) In the occasional case where I need to accept string Input for a complex field, like a Date, I have a binary field declared on the business interface, and the use helpers on the ActionForm to convert the field back and forth. But, with DynaBeans, this is becoming less and less of an issue, since it is very easy to just use DynaBeans as the missing HTTP data entry buffer and then pass the validated input off to a business bean. Though, there is still a ton maintenance going on here. We have the properties defined in the HTML form, and the struts-config, and in the validator.xml, and then in some type of corresponding property in the business bean, not to mention the actual data store. So to add a field, we have to update five (or more) components. The next step might be to try and combine the validator and DynaBeans definitions somehow, so that they can be maintained together. For many people, all the ActionForms do is validate input, which begs a single component. Heck, I could even imagine a tag that could generate many forms for you. If we were already defining the field, the validation, and the message, why not toss the control into the soup. The tag could look up the form definition and render the fields in order, using the specified control type. This wouldn't work for every case, but it might work for a great number of forms. So, then we'd be down to a single XML to define the form, the input properties, and their validators. So, then if you were using Hibernate, for example, you could end up maintaining two XMLs (one for Struts and one for Hibernate), along with the business entities (that are the point of the excersice). With Dynamic Forms, most of the HTML pages would be self-maintaining =:0) -Ted. Steve Raeburn wrote: OK, I definitely get the fact that you might need helper methods in addition to your html input properties. I guess I've just gotten into the habit of making ActionForms as simple as possible (actually I prefer DynaActionForms) and doing any conversions or manipulation in the Action. Given your example, I would use a DynaAction form to define the String input properties and have a completely seperate EmployeeDTO bean which I would populate in the Action. By having helper methods on the ActionForm you run the risk of infecting it with business logic. I haven't encountered a situation where it hasn't been possible to keep the ActionForm extremely simple. But I accept there might be situations that would warrant it. *BUT* there should be a bloody big health warning on the ActionForm documentation that says only ever use Strings! Steve -Original Message- From: Andrew Hill [mailto:[EMAIL PROTECTED] Sent: May 29, 2003 11:55 PM To: Struts Users Mailing List Subject: RE: Why do ActionForms allow non-string properties? Well firstly for dealing with nested forms, collections of nested forms and the like. One also needs to remember that the ActionForm is an object that represents the state of the UI - and depending on what you are doing you may wish to use it for storing information relating to ui state that doesnt map directly to a form control value, but is used in rendering the view. (ie: things relating to complex 'widgets' you render) You might also have properties
RE: Why do ActionForms allow non-string properties?
As one of the original whiners concerning the proliferation of config files, you know I'm on board! +2 ~m -Original Message- From: Vic Cekvenich [mailto:[EMAIL PROTECTED] Sent: Friday, May 30, 2003 10:15 AM To: [EMAIL PROTECTED] Subject: Re: Why do ActionForms allow non-string properties? we'd be down to a single XML to define the form, the input properties, and their validators. +1 .V Ted Husted wrote: Steve Raeburn wrote: *BUT* there should be a bloody big health warning on the ActionForm documentation that says only ever use Strings! Whether or not to only use Strings only matters if you care about capturing non-string input in a non-string field. Craig always felt that this use-case is very important, and many people agree. In practice, though, sometimes it doesn't matter. If they put AZ1234 in a field, the BeanUtils can quietly convert that to either null or zero. If the field is required, then they can be required to put in a valid, non-zero entry into it. For some clients, this is acceptable. As a consequence, if you have perfectly good business interface that you can otherwise apply to a ActionForm -- there you go, one less JavaBean protocol to maintain (at client's expense). Many people never even realize that there is any type of restriction here. A lot of application only use Strings to begin with. Or, the numbers are input through controls that put the numbers in for people. Or, the application requires clients to use JavaScript and a runtime Javascript keeps the focus on the field until they enter a valid number. I'm using some non-string ActionForm properties in my current application, and it's working just fine. We have exactly two fields that need actual numbers, and they are even required fields. For extra credit, I may try and snag invalid input and see if I can pump it into a validation message (AZ1234 is not a valid number). (Which, IMHO, is more appropriate than repopulating a field with invalid input.) In the occasional case where I need to accept string Input for a complex field, like a Date, I have a binary field declared on the business interface, and the use helpers on the ActionForm to convert the field back and forth. But, with DynaBeans, this is becoming less and less of an issue, since it is very easy to just use DynaBeans as the missing HTTP data entry buffer and then pass the validated input off to a business bean. Though, there is still a ton maintenance going on here. We have the properties defined in the HTML form, and the struts-config, and in the validator.xml, and then in some type of corresponding property in the business bean, not to mention the actual data store. So to add a field, we have to update five (or more) components. The next step might be to try and combine the validator and DynaBeans definitions somehow, so that they can be maintained together. For many people, all the ActionForms do is validate input, which begs a single component. Heck, I could even imagine a tag that could generate many forms for you. If we were already defining the field, the validation, and the message, why not toss the control into the soup. The tag could look up the form definition and render the fields in order, using the specified control type. This wouldn't work for every case, but it might work for a great number of forms. So, then we'd be down to a single XML to define the form, the input properties, and their validators. So, then if you were using Hibernate, for example, you could end up maintaining two XMLs (one for Struts and one for Hibernate), along with the business entities (that are the point of the excersice). With Dynamic Forms, most of the HTML pages would be self-maintaining =:0) -Ted. Steve Raeburn wrote: OK, I definitely get the fact that you might need helper methods in addition to your html input properties. I guess I've just gotten into the habit of making ActionForms as simple as possible (actually I prefer DynaActionForms) and doing any conversions or manipulation in the Action. Given your example, I would use a DynaAction form to define the String input properties and have a completely seperate EmployeeDTO bean which I would populate in the Action. By having helper methods on the ActionForm you run the risk of infecting it with business logic. I haven't encountered a situation where it hasn't been possible to keep the ActionForm extremely simple. But I accept there might be situations that would warrant it. *BUT* there should be a bloody big health warning on the ActionForm documentation that says only ever use Strings! Steve -Original Message- From: Andrew Hill [mailto:[EMAIL PROTECTED] Sent: May 29, 2003 11:55 PM To: Struts Users Mailing List Subject: RE: Why do ActionForms allow non-string properties? Well firstly for dealing with nested forms, collections of nested forms and the like
RE: Why do ActionForms allow non-string properties?
Though, there is still a ton maintenance going on here. We have the properties defined in the HTML form, and the struts-config, and in the validator.xml, and then in some type of corresponding property in the business bean, not to mention the actual data store. So to add a field, we have to update five (or more) components. In my XDoclet-enabled apps, if I had a new property, I only have to add it in two places - in my POJO and in my JSP. validation.xml is generated, as well as the ActionForm. Using Erik Hatcher's StrutsGen Tool, you can also generate a skeleton JSP from the generated ActionForm - but this is only logical to do the first time. I don't know if it'll ever be possible to eliminate the editing of the JSP - unless we add an XML file or something in the ActionForm that specifies field order, field type, etc. Still, there's so much custom stuff (label taglib, javascript pop-up calendars) that I put into forms, I doubt this will ever be possible. IMO, XDoclet is the best thing that's happened to Java Development since Ant. Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why do ActionForms allow non-string properties?
We look forward to your patches =:0) Get them in this morning, and I should be able to apply them tonight. Andrew Hill wrote: Well, I think it a bit restrictive to forbid non-string properties, but I would say that the docs really ought to make it clear that the recommended type for all those properties that directly relate to html controls should be strings. With that said, why does Struts even allow ActionForm properties to be anything other than String or boolean? As this seems to cause a lot of confusion would it not make sense to prevent other types? Or at least give stronger, more visible guidance about how to define ActionForm properties? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why do ActionForms allow non-string properties?
Still, there's so much custom stuff (label taglib, javascript pop-up calendars) that I put into forms, I doubt this will ever be possible. It's called a code generator and its already been done in other environments. The trade-off is that you lose some of the really fine control that is so attractive to programmers. You have to believe before it can happen! Most of the programmers I know give up on the generators in the belief they can program it faster. They probably can. But then somebody has to test EVERY LINE OF CODE. At that point I passed them up. Just some food for thought. --- Raible, Matt [EMAIL PROTECTED] wrote: Though, there is still a ton maintenance going on here. We have the properties defined in the HTML form, and the struts-config, and in the validator.xml, and then in some type of corresponding property in the business bean, not to mention the actual data store. So to add a field, we have to update five (or more) components. In my XDoclet-enabled apps, if I had a new property, I only have to add it in two places - in my POJO and in my JSP. validation.xml is generated, as well as the ActionForm. Using Erik Hatcher's StrutsGen Tool, you can also generate a skeleton JSP from the generated ActionForm - but this is only logical to do the first time. I don't know if it'll ever be possible to eliminate the editing of the JSP - unless we add an XML file or something in the ActionForm that specifies field order, field type, etc. Still, there's so much custom stuff (label taglib, javascript pop-up calendars) that I put into forms, I doubt this will ever be possible. IMO, XDoclet is the best thing that's happened to Java Development since Ant. Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why do ActionForms allow non-string properties?
:-D I had to chime in. I use complex objects in my forms so extensively because it makes my life easier when it comes to communcating with my business logic layer. It actually cuts down on the amount of manual transalting I have to do from one layer to another. It also cuts down on the amount of code I am writing. I DON'T think we should make a huge statement about Strings only. Strings do no handle all the situations that exists out there and often can be inhibiting when working with nested objects. It's silly to create String only beans to use in your forms and then communicate with the other layers by providing conversions between your string beans (no pun intended) and complex beans. YUCK!!! How about 10X more code and more code means more potential errors. I think that we should emphasis both scenarios. We should provide a reccommended way for using forms with complex (nested) objects and using basic flat String based (non-nested) forms. Brandon Goodin -Original Message- From: Lynn Guy [mailto:[EMAIL PROTECTED] Sent: Friday, May 30, 2003 10:10 AM To: Struts Users Mailing List Subject: RE: Why do ActionForms allow non-string properties? Still, there's so much custom stuff (label taglib, javascript pop-up calendars) that I put into forms, I doubt this will ever be possible. It's called a code generator and its already been done in other environments. The trade-off is that you lose some of the really fine control that is so attractive to programmers. You have to believe before it can happen! Most of the programmers I know give up on the generators in the belief they can program it faster. They probably can. But then somebody has to test EVERY LINE OF CODE. At that point I passed them up. Just some food for thought. --- Raible, Matt [EMAIL PROTECTED] wrote: Though, there is still a ton maintenance going on here. We have the properties defined in the HTML form, and the struts-config, and in the validator.xml, and then in some type of corresponding property in the business bean, not to mention the actual data store. So to add a field, we have to update five (or more) components. In my XDoclet-enabled apps, if I had a new property, I only have to add it in two places - in my POJO and in my JSP. validation.xml is generated, as well as the ActionForm. Using Erik Hatcher's StrutsGen Tool, you can also generate a skeleton JSP from the generated ActionForm - but this is only logical to do the first time. I don't know if it'll ever be possible to eliminate the editing of the JSP - unless we add an XML file or something in the ActionForm that specifies field order, field type, etc. Still, there's so much custom stuff (label taglib, javascript pop-up calendars) that I put into forms, I doubt this will ever be possible. IMO, XDoclet is the best thing that's happened to Java Development since Ant. Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.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: Why do ActionForms allow non-string properties?
Well, I think it a bit restrictive to forbid non-string properties, but I would say that the docs really ought to make it clear that the recommended type for all those properties that directly relate to html controls should be strings. -Original Message- From: Steve Raeburn [mailto:[EMAIL PROTECTED] Sent: Friday, 30 May 2003 14:14 To: Struts Users Mailing List Subject: Why do ActionForms allow non-string properties? This is a follow-up comment to an earlier thread: RE: URGENT: javax.servlet.ServletException: BeanUtils.populate As I understand it, you should only ever use String and boolean properties in an ActionForm because we're talking about an HTML form buffer here, not a business object. I've been looking for the definitive reference on this - I've found it before, but I can't find it right now. Ok, I've found some references... The ActionForm serves as the missing buffer for HTML controls. It preserves the input until it can be validated and transferred to another field of the appropriate type. If the user enters letters in an Integer field, the original input should be returned, including the invalid characters. A user can see what went wrong, correct the data, and try again. This also means that the ActionForm properties should be Strings so that *any* input can be captured, valid or not. ActionForms are not the *destination* of the input, but a *buffer* to be validated before the input is committed. -- Struts In Action, Ted Husted et al. All request parameters that are sent by the browser are strings. This is true regardless of the type that the value will eventually map to in Java. For example, dates, times, Booleans, and all other values are all strings when they are pulled out of the request, and they will be converted into strings when they are written back out to the HTML Page. Therefore, all of the ActionForm properties where the input may be invalid should be of type String, so that the data can be displayed back to the user in its original form when an error occurs. -- Programming Jakarta Struts, Chuck Cavaness With that said, why does Struts even allow ActionForm properties to be anything other than String or boolean? As this seems to cause a lot of confusion would it not make sense to prevent other types? Or at least give stronger, more visible guidance about how to define ActionForm properties? Steve - 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: Why do ActionForms allow non-string properties?
In what way would it be restrictive? Is there any reason you would need a non-string property (for html input) ? Steve -Original Message- From: Andrew Hill [mailto:[EMAIL PROTECTED] Sent: May 29, 2003 11:26 PM To: Struts Users Mailing List Subject: RE: Why do ActionForms allow non-string properties? Well, I think it a bit restrictive to forbid non-string properties, but I would say that the docs really ought to make it clear that the recommended type for all those properties that directly relate to html controls should be strings. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why do ActionForms allow non-string properties?
Well firstly for dealing with nested forms, collections of nested forms and the like. One also needs to remember that the ActionForm is an object that represents the state of the UI - and depending on what you are doing you may wish to use it for storing information relating to ui state that doesnt map directly to a form control value, but is used in rendering the view. (ie: things relating to complex 'widgets' you render) You might also have properties that are synonyms for string properties that act as convienience methods for getting and setting the value in its final type - but internally both reference the same String member variable. for example: private String _employeeSalary; private String _ceoSalary; setEmployeeSalary(String employeeSalary) String getEmployeeSalary() setEmployeeSalaryByte(Byte employeeSalary) Byte getEmployeeSalaryByte() setCeoSalary(String ceoSalary) String getCeoSalary() setCeoSalaryBigDecimal(BigDecimal ceoSalary) BigDecimal getCeoSalary() -Original Message- From: Steve Raeburn [mailto:[EMAIL PROTECTED] Sent: Friday, 30 May 2003 14:40 To: Struts Users Mailing List Subject: RE: Why do ActionForms allow non-string properties? In what way would it be restrictive? Is there any reason you would need a non-string property (for html input) ? Steve -Original Message- From: Andrew Hill [mailto:[EMAIL PROTECTED] Sent: May 29, 2003 11:26 PM To: Struts Users Mailing List Subject: RE: Why do ActionForms allow non-string properties? Well, I think it a bit restrictive to forbid non-string properties, but I would say that the docs really ought to make it clear that the recommended type for all those properties that directly relate to html controls should be strings. - 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: Why do ActionForms allow non-string properties?
OK, I definitely get the fact that you might need helper methods in addition to your html input properties. I guess I've just gotten into the habit of making ActionForms as simple as possible (actually I prefer DynaActionForms) and doing any conversions or manipulation in the Action. Given your example, I would use a DynaAction form to define the String input properties and have a completely seperate EmployeeDTO bean which I would populate in the Action. By having helper methods on the ActionForm you run the risk of infecting it with business logic. I haven't encountered a situation where it hasn't been possible to keep the ActionForm extremely simple. But I accept there might be situations that would warrant it. *BUT* there should be a bloody big health warning on the ActionForm documentation that says only ever use Strings! Steve -Original Message- From: Andrew Hill [mailto:[EMAIL PROTECTED] Sent: May 29, 2003 11:55 PM To: Struts Users Mailing List Subject: RE: Why do ActionForms allow non-string properties? Well firstly for dealing with nested forms, collections of nested forms and the like. One also needs to remember that the ActionForm is an object that represents the state of the UI - and depending on what you are doing you may wish to use it for storing information relating to ui state that doesnt map directly to a form control value, but is used in rendering the view. (ie: things relating to complex 'widgets' you render) You might also have properties that are synonyms for string properties that act as convienience methods for getting and setting the value in its final type - but internally both reference the same String member variable. for example: private String _employeeSalary; private String _ceoSalary; setEmployeeSalary(String employeeSalary) String getEmployeeSalary() setEmployeeSalaryByte(Byte employeeSalary) Byte getEmployeeSalaryByte() setCeoSalary(String ceoSalary) String getCeoSalary() setCeoSalaryBigDecimal(BigDecimal ceoSalary) BigDecimal getCeoSalary() - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Why do ActionForms allow non-string properties?
Besides, Strings are central to the language - that's why, unlike in other languages, String is a separate, immutable class. You can cast a String to anything, and anything to a String. I only use Strings in my ActionForms and only HashMaps containing Strings in my DynaActionForms. It is no trouble at all to cast the objects to the desired form for, like calculating BigDecimals or using a boolean in a conditional. I also store everything in the database as Strings - even dates. This greatly simplifies data manipulation, and avoids st00pid errors like trying to store floats in the db and expecting a query return with a precision limited to 2. Mark -Original Message- From: Andrew Hill [mailto:[EMAIL PROTECTED] Sent: Friday, May 30, 2003 2:55 AM To: Struts Users Mailing List Subject: RE: Why do ActionForms allow non-string properties? Well firstly for dealing with nested forms, collections of nested forms and the like. One also needs to remember that the ActionForm is an object that represents the state of the UI - and depending on what you are doing you may wish to use it for storing information relating to ui state that doesnt map directly to a form control value, but is used in rendering the view. (ie: things relating to complex 'widgets' you render) You might also have properties that are synonyms for string properties that act as convienience methods for getting and setting the value in its final type - but internally both reference the same String member variable. for example: private String _employeeSalary; private String _ceoSalary; setEmployeeSalary(String employeeSalary) String getEmployeeSalary() setEmployeeSalaryByte(Byte employeeSalary) Byte getEmployeeSalaryByte() setCeoSalary(String ceoSalary) String getCeoSalary() setCeoSalaryBigDecimal(BigDecimal ceoSalary) BigDecimal getCeoSalary() -Original Message- From: Steve Raeburn [mailto:[EMAIL PROTECTED] Sent: Friday, 30 May 2003 14:40 To: Struts Users Mailing List Subject: RE: Why do ActionForms allow non-string properties? In what way would it be restrictive? Is there any reason you would need a non-string property (for html input) ? Steve -Original Message- From: Andrew Hill [mailto:[EMAIL PROTECTED] Sent: May 29, 2003 11:26 PM To: Struts Users Mailing List Subject: RE: Why do ActionForms allow non-string properties? Well, I think it a bit restrictive to forbid non-string properties, but I would say that the docs really ought to make it clear that the recommended type for all those properties that directly relate to html controls should be strings. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Why do ActionForms allow non-string properties?
Steve Raeburn wrote: *BUT* there should be a bloody big health warning on the ActionForm documentation that says only ever use Strings! Whether or not to only use Strings only matters if you care about capturing non-string input in a non-string field. Craig always felt that this use-case is very important, and many people agree. In practice, though, sometimes it doesn't matter. If they put AZ1234 in a field, the BeanUtils can quietly convert that to either null or zero. If the field is required, then they can be required to put in a valid, non-zero entry into it. For some clients, this is acceptable. As a consequence, if you have perfectly good business interface that you can otherwise apply to a ActionForm -- there you go, one less JavaBean protocol to maintain (at client's expense). Many people never even realize that there is any type of restriction here. A lot of application only use Strings to begin with. Or, the numbers are input through controls that put the numbers in for people. Or, the application requires clients to use JavaScript and a runtime Javascript keeps the focus on the field until they enter a valid number. I'm using some non-string ActionForm properties in my current application, and it's working just fine. We have exactly two fields that need actual numbers, and they are even required fields. For extra credit, I may try and snag invalid input and see if I can pump it into a validation message (AZ1234 is not a valid number). (Which, IMHO, is more appropriate than repopulating a field with invalid input.) In the occasional case where I need to accept string Input for a complex field, like a Date, I have a binary field declared on the business interface, and the use helpers on the ActionForm to convert the field back and forth. But, with DynaBeans, this is becoming less and less of an issue, since it is very easy to just use DynaBeans as the missing HTTP data entry buffer and then pass the validated input off to a business bean. Though, there is still a ton maintenance going on here. We have the properties defined in the HTML form, and the struts-config, and in the validator.xml, and then in some type of corresponding property in the business bean, not to mention the actual data store. So to add a field, we have to update five (or more) components. The next step might be to try and combine the validator and DynaBeans definitions somehow, so that they can be maintained together. For many people, all the ActionForms do is validate input, which begs a single component. Heck, I could even imagine a tag that could generate many forms for you. If we were already defining the field, the validation, and the message, why not toss the control into the soup. The tag could look up the form definition and render the fields in order, using the specified control type. This wouldn't work for every case, but it might work for a great number of forms. So, then we'd be down to a single XML to define the form, the input properties, and their validators. So, then if you were using Hibernate, for example, you could end up maintaining two XMLs (one for Struts and one for Hibernate), along with the business entities (that are the point of the excersice). With Dynamic Forms, most of the HTML pages would be self-maintaining =:0) -Ted. Steve Raeburn wrote: OK, I definitely get the fact that you might need helper methods in addition to your html input properties. I guess I've just gotten into the habit of making ActionForms as simple as possible (actually I prefer DynaActionForms) and doing any conversions or manipulation in the Action. Given your example, I would use a DynaAction form to define the String input properties and have a completely seperate EmployeeDTO bean which I would populate in the Action. By having helper methods on the ActionForm you run the risk of infecting it with business logic. I haven't encountered a situation where it hasn't been possible to keep the ActionForm extremely simple. But I accept there might be situations that would warrant it. *BUT* there should be a bloody big health warning on the ActionForm documentation that says only ever use Strings! Steve -Original Message- From: Andrew Hill [mailto:[EMAIL PROTECTED] Sent: May 29, 2003 11:55 PM To: Struts Users Mailing List Subject: RE: Why do ActionForms allow non-string properties? Well firstly for dealing with nested forms, collections of nested forms and the like. One also needs to remember that the ActionForm is an object that represents the state of the UI - and depending on what you are doing you may wish to use it for storing information relating to ui state that doesnt map directly to a form control value, but is used in rendering the view. (ie: things relating to complex 'widgets' you render) You might also have properties that are synonyms for string properties that act as convienience methods for getting and setting the value in its final type - but internally
