RE: [Springframework-developer] Form View and Results View on same page issue.

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Trevor,

I would also like to see your controller as I been banging my head over the
same type scenario.  Would you be willing to post it to the group?

Thanks,

Shane Walters

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Trevor Cook
Sent: Tuesday, February 17, 2004 8:06 AM
To: spr...@li...
Subject: RE: [Springframework-developer] Form View and Results View on
same page issue.

>>I believe that the controller shouldn't have to be altered just because
it's returning to the same view
While this sounds good, the problem is there are 2 pieces, the model and
view.  You can use the same view by simply setting successView the same as
formView.  The issue is that other methods (like referenceData) are not
generating the model correctly.  While this is wrong in the scenario you
describe, generating the model for successView all the time would mean a
bloated model for the current usage where you are sending to a different
view.

Another simple way to handle this is to use "return showForm(...)" in the
onSubmit method.  I personally don't like this, mainly because you still
have extra baggage in the SimpleFormController that you aren't using.

I'll post my controller this afternoon.

Trevor

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of William Lyvers
Sent: February 17, 2004 8:40 AM
To: spr...@li...
Subject: RE: [Springframework-developer] Form View and Results View on
same page issue.

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
>

-------------------------------------------------------
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