|
From: William L. <wi...@ly...> - 2004-02-17 13:44:23
|
First, you described the problem correctly. The link you sent is the exact scenario that I was describing. When I first realized that SimpleFormController wasn't going to support this type of page out of the box, I looked at extended BaseCommandController as you have done. I resisted this mainly for 2 reasons. 1. As you mentioned, it was yet another FormController and I didn't thing it was likely that it would be pulled back into Spring since there are already about 5 flavors of controllers. Arguably, there may already be too many versions of controllers within the Framework. 2. Personally, I believe that the controller shouldn't have to be altered just because it's returning to the same view. I should be able to return a success view string and not have to alter my subclass just because I am reposting back to the same form. In either case, this is such a common scenario I would hope that the Spring Framework would support this out of the box by either another CommandController as you have suggested or enhancing SimpleFormController as I did in the first part of this thread. Thanks, Bill Lyvers I would be very interested in seeing your SelfPostingFormController. It is probably a much simpler workflow since you know you are only working with one view. ---------- Original Message ---------------------------------- From: "Trevor Cook" <tc...@in...> Reply-To: spr...@li... Date: Mon, 16 Feb 2004 22:18:54 -0500 >It sounds like your problem is with the workflow of SimpleFormController. >Before recommending an option, let me clarify what you are trying to do. It >sounds like it should be: > >- use posted bean to determine search params (if it exists - for "get" use >default values of search-param bean) >- return view with search results > >You don't need a "FormView"/"SuccessView", just a single view. You also >would need any "referenceData" like method to be called before returning the >view, regardless of get/post. Is this a correct understanding of your >problem? If so, take a quick look at something I've implemented at >http://www.fotosource.com/my_local_store.html . Basically, the filters >above the search results are constantly redisplayed with changing results >underneath. The form also works for an initial get request (with no search >filters) and then successive posts (through the filter button). > >I implemented this by extending BaseCommandController >(SimpleFormController's "grandfather"). You can probably simply implement >what you're looking for by extending this class (or if necessary, step back >another level to AbstractController). I never contributed this class (I >called it "SelfPostingFormController") because it was fairly simple to >implement, and considering most custom apps functionality is "exactly like >class X except for Y" I didn't want to bloat Spring. Would this type of >class be generally useful (or has another developer already snuck this in)? >If multiple users want this I'll add it, otherwise I'll just post the code >seperately for you to use. > >Trevor > > >-----Original Message----- >From: spr...@li... >[mailto:spr...@li...]On Behalf >Of wi...@ly... >Sent: February 16, 2004 7:18 PM >To: spr...@li... >Subject: Re: [Springframework-developer] Form View and Results View on >same page issue. > > >I posted this late last week but didn't get any bites -- maybe I'll try >a different angle :). >In short, I believe that the SimpleFormController should be enhanced to >support posting results back to the originating form page. The current >implementation requires implementing classes to know they are returning >back to the originating form page. This limits the generic ability of >wiring up views via IOC and getSuccessView() on SimpleFormHandler. >Since this is such a common scenario, I was hoping this could be >addressed prior to the 1.0 release. Thoughts? > >Bill Lyvers > > >wi...@ly... wrote: > >> I recently started using the web framework portion of Spring. One >> concept in particular has bitten me a couple of times and I have been >> unable to determine a best practice. The concept is how >> SimpleFormHandler has a different workflow based on whether it is a >> get request versus a post request. This concept seemed very intuitive >> and works fine if the post goes off to a result page. However, below >> is a scenario that I believe is quite common and SimpleFormHandler >> doesn't seem to deal with it very elegantly. The problem arises when >> a page displays both a form and the results of a form post on the same >> page. >> >> Scenario: >> There is item search page with a item search form on the top and a >> tabular view of the item search results below the search page. >> >> Example Controller: >> public class ItemSearchController extends SimpleFormController { >> private ItemManager manager; >> public void setSearchManager(ItemManager manager) { >> this.manager = manager; >> } >> protected Map referenceData(HttpServletRequest request) throws >> Exception { >> Map map = new HashMap(); >> map.put( "itemTypes", manager.getItemTypes() ); >> return map; >> } >> protected ModelAndView onSubmit(Object object) throws Exception { >> Item command = (Item)object; >> return new ModelAndView( getSuccessView(), "items", >> manager.findItemsByExample( command )); >> } >> } >> >> So, I request the page via /searchItem.htm which maps >> ItemSearchController. The "get" workflow works as usual -- >> referenceData gets called and the page displays fine. The user >> submits a search criteria which then goes through "post" workflow and >> onSubmit gets called which returns a list of items via ModelAndView. >> The successView now needs to return to the same page and this time the >> results will be displayed below the form. However, >> 1. If I forward back to /searchItem.htm, then I end up in an >> infinite loop because the controller keeps processing it as a post. >> 2. If I forward on to the jsp that displayed the form originally, I >> will not go through the same workflow as when the page was first >> loaded and referenceData won't get called. Not too mention that I'll >> get an binding errors missing exception -- I saw that RC1 tried to >> address this, but only if you don't override onsubmit. >> >> So, I decided to solve the problem with option 1 and cause the form to >> realize that the post had already been handled and it must be a "get" >> request being caused by a forward. The main reason for this is that >> the get workflow gets used when entering the page each. To fix it, I >> overrode isFormSubmission and set an attribute when a formSubmission >> was recognized. If this attribute already exists, it assumes that it >> is a get request instead. Example: >> protected boolean isFormSubmission(HttpServletRequest >> httpServletRequest) { >> Object alreadySubmitted = httpServletRequest.getAttribute( >> "formSubmission"); >> if (alreadySubmitted != null) { >> return false; >> } >> boolean formSubmission = >> super.isFormSubmission(httpServletRequest); >> if( formSubmission ) { >> httpServletRequest.setAttribute( "formSubmission", >> Boolean.TRUE ); >> } >> return formSubmission; >> } >> >> >> I am a surprised that SimpleFormController doesn't deal with this >> scenario since it is so common or maybe I am missing something and it >> does. With the above code you can switch out the success view to go >> to a seperate result page later by just changing the IOC >> configuration. Basically, your controller doesn't really need to >> know that the results page is the same view as the form view. >> >> I am very curious on how others are dealing with this scenario and if >> Spring deals with it and I have just overlooked it. >> >> Keep up the good work, >> Bill Lyvers >> >> >> >> >> >> >> >> ------------------------------------------------------- >> SF.Net is sponsored by: Speed Start Your Linux Apps Now. >> Build and deploy apps & Web services for Linux with >> a free DVD software kit from IBM. Click Now! >> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click >> _______________________________________________ >> Springframework-developer mailing list >> Spr...@li... >> https://lists.sourceforge.net/lists/listinfo/springframework-developer >> >> > > > > >------------------------------------------------------- >SF.Net is sponsored by: Speed Start Your Linux Apps Now. >Build and deploy apps & Web services for Linux with >a free DVD software kit from IBM. Click Now! >http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > > > >------------------------------------------------------- >SF.Net is sponsored by: Speed Start Your Linux Apps Now. >Build and deploy apps & Web services for Linux with >a free DVD software kit from IBM. Click Now! >http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click >_______________________________________________ >Springframework-developer mailing list >Spr...@li... >https://lists.sourceforge.net/lists/listinfo/springframework-developer > |