You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Steve Raeburn <st...@ninsky.com> on 2003/05/30 08:13:34 UTC
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: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Why do ActionForms allow non-string properties?
Posted by Ted Husted <hu...@apache.org>.
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: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: Why do ActionForms allow non-string properties?
Posted by Mark Galbreath <ma...@qat.com>.
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:andrew.david.hill@gridnode.com]
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:steve@ninsky.com]
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:andrew.david.hill@gridnode.com]
> 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: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: how can I find the Scaffold package?
Posted by Denis Avdic <de...@betterway.net>.
Leon wrote:
>Hi,
>
>What is the download link of the Scaffold package?
>Thanks.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
>
>
>
How about you do a google search on that? It took me exactly 1min 15
secs to find a download of the Scaffold package.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
how can I find the Scaffold package?
Posted by Leon <le...@hotmail.com>.
Hi,
What is the download link of the Scaffold package?
Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: Why do ActionForms allow non-string properties?
Posted by Mark Galbreath <ma...@qat.com>.
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:vc@baseBeans.com]
Sent: Friday, May 30, 2003 10:15 AM
To: struts-user@jakarta.apache.org
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:andrew.david.hill@gridnode.com]
>>> 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: struts-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>
>>
>
>
--
Vic Cekvenich,
Struts Instructor,
1-800-917-JAVA
Advanced <a href ="baseBeans.com">Struts Training</a> and project recovery
in North East. Open Source <a href ="baseBeans.com">Content Management</a>
basicPortal sofware Best practice<a href ="baseBeans.com">Struts Support</a>
v.1.1 helper ScafflodingXPress
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Why do ActionForms allow non-string properties?
Posted by Vic Cekvenich <vc...@baseBeans.com>.
" 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:andrew.david.hill@gridnode.com]
>>> 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: struts-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>>
>>
>
>
--
Vic Cekvenich,
Struts Instructor,
1-800-917-JAVA
Advanced <a href ="baseBeans.com">Struts Training</a> and project recovery in North East.
Open Source <a href ="baseBeans.com">Content Management</a> basicPortal sofware
Best practice<a href ="baseBeans.com">Struts Support</a> v.1.1 helper ScafflodingXPress
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Why do ActionForms allow non-string properties?
Posted by Ted Husted <hu...@apache.org>.
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:andrew.david.hill@gridnode.com]
>>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: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
--
Ted Husted,
Struts in Action <http://husted.com/struts/book.html>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: Why do ActionForms allow non-string properties?
Posted by Steve Raeburn <st...@ninsky.com>.
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:andrew.david.hill@gridnode.com]
> 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: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: Why do ActionForms allow non-string properties?
Posted by Andrew Hill <an...@gridnode.com>.
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:steve@ninsky.com]
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:andrew.david.hill@gridnode.com]
> 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: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: Why do ActionForms allow non-string properties?
Posted by Steve Raeburn <st...@ninsky.com>.
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:andrew.david.hill@gridnode.com]
> 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: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: Why do ActionForms allow non-string properties?
Posted by Andrew Hill <an...@gridnode.com>.
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:steve@ninsky.com]
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: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org