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?
"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?
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?
> 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?
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
>&
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:
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 co
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?
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?
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?
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, 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]
