+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 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]
-- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
