I think this is how I might have to treat my code. It's
a shame really because I've got a good connection between
my forms being dynmically built at the data beans
the data comes from.
For something like dates though, I'll use some funky
JavaScript to handle the formating.
Dmitri Plotnikov wrote:
>
> I don't know if my understanding of the purpose of
> ActionForm is correct, but I have been treating them
> as part of the View. Hence I have been designing the
> APIs of ActionForm with the needs of the JSP(s) in
> mind. For example, all attributes bound to text
> fields are declared as Strings. My ActionForms
> function as adapters to the model JavaBeans and EJBs,
> they are responsible for necessary type convertions.
> For example, field "dateOfBirth" is always declared as
> String on the ActionForm, but as Date on the model
> bean. An action method (e.g. "save()") pushes data
> into the model, converting types as needed. When my
> ActionForm needs nested objects, I create new,
> UI-oriented classes for those as well.
>
> If my understanding of the role of ActionForms is
> right, no enhancement of the form population mechanism
> is needed.
