RE: [Springframework-developer] MVC Forms

[<jue...@we...>]

Ken,

I've further refined invalid submission handling. An invalid submit =
request in session form mode (i.e. when no form object is in the =
session) triggers AbstractFormController's handleInvalidSubmit method. =
The latter's default implementation simply shows a new form, binding the =
submitted values to the new form in case of "bindOnNewForm=3Dtrue". But =
handleInvalidSubmit can be overridden now, to show an "invalid resubmit" =
error message or redirect to some other view.

Regarding transaction tokens: In session mode, form objects can serve as =
transaction tokens. If a user presses the browser's reload button, he =
either sees a new form or some custom error message (as determined by =
the handleInvalidSubmit implementation). Thus, if you need to forbid =
duplicate submissions for a certain form, switch its controller into =
session form mode in any case (even if you wouldn't need to keep the =
form object in the session otherwise).

Thus, we don't really need dedicated transaction token support - just =
leverage AbstractFormController's invalid submission handling in session =
form mode. A dedicated token attribute in the session would only be =
necessary if there isn't any form object involved. Do you see a use case =
for forbidding duplicate submissions without a form?

Struts has programmatic token support: You can manually add it to a =
session/request in an Action implementation when showing the form, and =
manually check its validity on submit. The html:form tag automatically =
adds a respective hidden field. I don't see actual value in this, =
though, beyond what proper session form handling already provides. BTW, =
transaction tokens aren't even mentioned in the Struts User Guide.

Regards,
Juergen


-----Original Message-----
From: Ken Krebs [mailto:kk...@kk...]
Sent: Tuesday, May 20, 2003 7:21 PM
To: j=FCrgen h=F6ller [werk3AT]
Cc: 'spring-dev-list'
Subject: Re: [Springframework-developer] MVC Forms


Juergen,

I haven't had a chance to look at them but your changes for the Back=20
button problems, including some way of forbidding duplicate submission=20
(hopefully possible through configuration of the form bean), sound like=20
they will help provide what's needed and are a real plus for developers. =

I will try to point this out in the accompanying tutorial text.

As for AbstractFormController and SimpleFormController seeming=20
restrictive, this was probably just a perception I got as I tried to=20
solve the Back button issue. My own AbstractSearchFormController=20
subclass of SimpleFormController shows that it is not restrictive on=20
submission. I was concerned about how to handle things going wrong prior =

to submission (see next paragraph).

There is another class of MVC problem not necessarily just with forms,=20
and that is when the user directly enters a mapped url to a Controller,=20
and the Controller expects to see parameters that aren't there. An=20
example of my own handling of this in petclinic is in the method=20
ClinicController.ownerHandler. In this case, it's makes sense to just=20
redirect the user to the FindOwnerForm as I've done. I was planning on=20
handling this situation for the OwnerInfoForm by making the form=20
dynamically show a "Update Owner Info" button if the preconfigured=20
object can be provided or a "Add Owner" button if there is no=20
preconfigured object, but redirection may be desirable in some=20
situations. What do you think ?

 From the viewpoint of an organization considering adopting Spring, the=20
fact that Spring addresses these problems directly without individual=20
developers having to craft their own adhoc solutions should be seen as a =

plus.

Ken