Re: [Springframework-developer] MVC Forms

[Ken K. <kk...@kk...>]

Juergen,

I haven't had a chance to look at them but your changes for the Back 
button problems, including some way of forbidding duplicate submission 
(hopefully possible through configuration of the form bean), sound like 
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 
restrictive, this was probably just a perception I got as I tried to 
solve the Back button issue. My own AbstractSearchFormController 
subclass of SimpleFormController shows that it is not restrictive on 
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, 
and that is when the user directly enters a mapped url to a Controller, 
and the Controller expects to see parameters that aren't there. An 
example of my own handling of this in petclinic is in the method 
ClinicController.ownerHandler. In this case, it's makes sense to just 
redirect the user to the FindOwnerForm as I've done. I was planning on 
handling this situation for the OwnerInfoForm by making the form 
dynamically show a "Update Owner Info" button if the preconfigured 
object can be provided or a "Add Owner" button if there is no 
preconfigured object, but redirection may be desirable in some 
situations. What do you think ?

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

Ken

jürgen höller [werk3AT] wrote:

>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ürgen höller [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 
>try and resubmit the form (which has sessionForm==true) to make another 
>change, the method AbstractFormController.handleRequestInternal will 
>call userObject to retrieve the form object from the session. Since the 
>form object is no longer there, this results in a ServletException. My 
>current working version works around this by overriding isFormSubmission 
>which only returns true if the method was POST and it can find the form 
>object. Since I have also overriden formBackingObject to provide the 
>owner info in the first place, this results in a redisplay of the form 
>with the user's latest changes silently ignored. This process must seem 
>unreasonable to users who know nothing about the problems enterprise 
>application developers face with the browser's Back button. Maybe I'm 
>going about this wrong.
>
>This also brings up the issue of when a developer specifically wants to 
>forbid resubmission as in a purchase transaction. Struts provides 
>support for a synchronizing token to prevent duplicate submissions using 
>the <html:form> tag.
>
>Perhaps we should provide some infrastructure to help developers solve 
>these problems in a consistent way.
>
>I am also a little bit concerned over the process used in 
>AbstractFormController and SimpleFormController. Developers may see this 
>as too restrictive, especially if they are used to the flexible 
>forwarding strategy of Struts.
>
>What are your thoughts on this ?
>
>Ken
> 
>
>
>
>  
>