John Yu wrote:
> Struts is clever enough to call myEmployeeBean.getEmployeeVO().getName().
Something to watch is that Struts is also clever enough to populate any
String or boolean public property property on employeeVO from a query
string. So if employeeVO had another property, like role, someone might
be able to set that from a query string like
/do/employeeSubmit?role=MANAGER
and have the employee's role set to MANAGER -- even if that property
were not exposed on the ActionForm. Of course, this wouldn't actually
work in most use cases, but it is something to keep in mind.
It's important to recognize that ActionForms are firewalls between the
rest HTTP and the rest of your application. Once the (untrusted)
ActionForm properties are validated, the data can be moved to another
(trusted) class, and handled optimistically.
Personally, I recommend keeping the ActionForms as throw-away UI
artifacts. An environment like Swing does the same thing, an internal
buffer captures input as a String, and then converts or passes the
validated result back, but without exposing the buffer property to the
developer. The same strategy is at work here, but since we can't extend
the browser controls, we have to provide our own ActionForm instead.
If the value objects are also transient, and the fields are Strings or
booleans, then it can be reasonable to to populate the String properties
directly from the ActionForm. Though, many forms have to deal with more
than Strings. Where do you store an invalid date or integer so the user
can correct it? This is why ActionForms usually need to be separate
objects -- for non-String fields that can't be passed back and forth via
HTTP ~in an invalid state~.
If a user enters $1.00 where they were suppose to enter 1.00 and
returning a blank instead of what they entered is acceptable, then you
can wrap a double currency field in an ActionForm. Otherwise, there will
not be a way to return the original input, since "$" can't be stored in
a numeric field. Of course, Javascript validations can address this, but
the framework cannot be premised on Javascript being available.
The next best thing would be to give the binary fields on the value
object String buffers, which is how conventional UI components work. But
then you really should build a validation state into the value object
too, which can lead to buffering all the fields, including the String
fields. At this point, the value object is more complicated that having
a separation ActionForm, and requires no less typing.
Personally, I recommend using the BeanUtils methods to populate value
objects from validated ActionForms. Since these use reflection, they
tend to the fastest, easiest, and cheapest way to get the job done. You
can even build this into your Action subclass, so custom methods are not
continually loaded through the application.
It's also important to note that there doesn't not have to be 1:1
relationship between ActionForms and the value objects. The ActionForms
represent input required from the user. This may map to several value
objects, and the value objects may carry other fields. Each to its own.
Representing dates and other formatted data can still be a problem.
Here, I tend to add ${property}Text fields to the value objects, that
accept and return String representations of dates, telephone numbers,
and other formatted strings, that may have to be transformed before
being stored or accessed. These are still not bound to the ActionForm in
any way, except by name. So instead of having a "date" property, an
ActionForm might have a dateText property. On the value object, the
setDateText method sets the actual date property on a pass/fail basis,
so it's important that the ActionForm validate the date String first.
ActionForm
- dateText: String
+ setDateText:String
+ getDataeText:String
ValueObject
- date:Timestamp
+ setDate:Timestamp
+ getDate:Timestamp
+ setDateText:String
+ getDateText:String
Of course the simple native types, found in java.lang, once validated,
can usually pass right through, without intervention. But in practice,
many fields need to be formatted before being presented to the user, and
the formatting removed before the value is updated.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel +1 716 737-3463
-- http://www.husted.com/struts/
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
