Hi Craig,
> My thinking on multi-page forms is definitely not totally finished yet,
but my
> operating assumption has been that you'd have separate actions for each
page, so
> you could therefore direct errors back to the individual pages. The
logical
> "grouping" of the actions could happen by subclassing a common base class
that
> represented the shared logic. You would declare the same form bean for
all of
> these actions, and you'd store this bean in session scope. (As a side
benefit,
> you can also use "next" and "previous" logical forward names directly,
without
> having to calculate which page you are on in sequence, and then know what
the
> next and previous logical names are.)
>
> It is still messy, because the validation method (at least) needs to know
what
> fields came from what pages, and there is no convenient way to communicate
that
> information so that it only needs to be specified once. I think that a
final
> solution to this is probably going to need to wait for a 1.1 time frame,
when we
> can figure out how to deal with it cleanly. I believe that the current
approach
> works quite well for single page forms (with the outstanding issue of
people
> that want to deal with dynamic sets of properties, rather than fixed ones,
which
> will need to be a separate extension if we decide to support it).
Thanks for your explanation.
I've not yet played with multi-page forms, though the <action> example I
included had one. Your design allows to discriminate on the mapping for the
validation call, and make local validation simpler.
My design problem was to consider the ActionForm as the central element and
to offer different views on it with the different forwards of a unique
Action, instead of creating multiple ActionForm. I will wait for version 1.1
to change my code.
Pierre Métras
