FW: [Springframework-developer] MVC Forms

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

Reply-to...

-----Original Message-----
From: j=FCrgen h=F6ller [werk3AT]=20
Sent: Tuesday, May 20, 2003 6:00 PM
To: 'Ken Krebs'
Subject: RE: [Springframework-developer] MVC Forms


Hi Ken,

Hmmm, those naughty back button problems ;-)

Anyway, you're right that going back and resubmitting the form currently =
results in a "Form object not found" message when using session form =
mode (in non-session mode it would work of course). This isn't =
particularly nice, so I've just added a corresponding check to =
AbstractFormController's handleRequestInternal. A request without a form =
session attribute is now always treated as new form when in session form =
mode.

To avoid the silent ignoring of a user's changes in this case, I've =
added a general new feature: a "bindOnNewForm" property. If this is true =
-setBindOnNewForm(true) or a bean factory parameter -, the parameters of =
a request that leads to a new form get bound to the form object too. =
This can be used to prepopulate a new form via the calling URL, but it =
also keeps the user's changes in the back-and-resubmit case when using =
session form mode.

Forbidding resubmissions is a good point. I'm aware of Struts' support =
for tokens, and I've repeatedly thought about adding support for this to =
Spring too. I'll probably add this sooner, maybe even this week :-)

What about AbstractFormController and SimpleFormController do you =
consider restrictive? Resp. what do you mean with Struts' flexible =
forwarding strategy? AFAIK, you can preconfigure the form view and =
success view in struts-config. SimpleFormController offers a similar =
model: Simply preconfigure formView and successView via the application =
context's definition of your controller, instead of calling setFormView =
and setSuccessView in your constructor.

So with Struts, you _must_ use symbolic view names in struts-config, =
using the one and only view resolution way. With Spring, you have the =
choice between defining the views in the form controller and using the =
application context definition. Additionally, you can choose between =
various ViewResolver implementations. If you want even more flexibility, =
you can derive from AbstractFormController, providing showForm and =
processSubmit yourself.

I've already committed the changes to AbstractFormController, please =
have a look at them!

Regards,
Juergen


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


Juergen,

There is a problem in my version 1 prototype of the petclinic demo.

Should a user change an owner's info and then use the Back button and=20
try and resubmit the form (which has sessionForm=3D=3Dtrue) to make =
another=20
change, the method AbstractFormController.handleRequestInternal will=20
call userObject to retrieve the form object from the session. Since the=20
form object is no longer there, this results in a ServletException. My=20
current working version works around this by overriding isFormSubmission =

which only returns true if the method was POST and it can find the form=20
object. Since I have also overriden formBackingObject to provide the=20
owner info in the first place, this results in a redisplay of the form=20
with the user's latest changes silently ignored. This process must seem=20
unreasonable to users who know nothing about the problems enterprise=20
application developers face with the browser's Back button. Maybe I'm=20
going about this wrong.

This also brings up the issue of when a developer specifically wants to=20
forbid resubmission as in a purchase transaction. Struts provides=20
support for a synchronizing token to prevent duplicate submissions using =

the <html:form> tag.

Perhaps we should provide some infrastructure to help developers solve=20
these problems in a consistent way.

I am also a little bit concerned over the process used in=20
AbstractFormController and SimpleFormController. Developers may see this =

as too restrictive, especially if they are used to the flexible=20
forwarding strategy of Struts.

What are your thoughts on this ?

Ken
=20