Thanks for the speedy response Ben.
Reverting to the <%@ include %> worked in all applicable cases.
Your assumptions about non-AJAX situations are thought-provoking. We
encountered problems with STS-632 specifically where we offer a ³flat² and
³modal² version of forms; the flat form submission being a standard
full-page response, and the modal being handled with AJAX throughout.
It would be great if there was a way to handle Form processing that exists
entirely in an AJAX context in a cleaner way within Stripes. We have
encountered some issues with creating forms on-the-fly using Jquery and then
posting to a Stripes ActionBean without appropriating a page-level
_sourcePage parameter. Ideally we would be able to handle form submission
with a token not bound to the page path.
- Mark Tyrrell
On 3/11/09 7:44 PM, "Ben Gunter" wrote:
> Yes, there was such a change.
>
> http://www.stripesframework.org/jira/browse/STS-632
>
> I did that to better support AJAX. For example, say you have A.jsp, which
> includes a form from B.jsp. The form in B.jsp is submitted with AJAX and the
> response replaces the form. However, if there are validation errors in your
> form submission you'd want it to return only the contents of B.jsp with the
> validation errors included. Otherwise, you'd end up with the whole contents of
> A.jsp (including B.jsp) inside an element in the page already rendered from
> A.jsp.
>
> It was only after the release of 1.5.1 that I realized the potential problems
> it would cause for non-AJAX situations. There is a workaround. Try replacing
> your with <%@ include %>. The latter literally includes the
> source of the target page without making a new "include" request. The result
> is that _sourcePage becomes the outer page instead of the included one.
>
> I know this isn't ideal for you, but at least there is a workaround when it's
> done this way. I never could come up with a workaround when the behavior was
> the other way.
>
> I'm open to discussion on the topic. Let me know if you have any suggestions
> or if you simply can't get it to work.
>
> -Ben
>
> On Wed, Mar 11, 2009 at 7:16 PM, Mark Tyrrell wrote:
>> Here is a summary of how we reproduce this problem (which does not happen
>> with Stripes 1.5):
>>
>> 1) Request /sign-in which resolves to the default handler method view() on
>> our SignInActionBean which has the following annotations:
>> �...@defaulthandler
>> �...@dontvalidate
>> Response uses JSP specified in the returned ForwardResolution
>> 2) Click on form submit button
>> 3) Stripes processes request and correctly resolves the login() method and
>> the required fields are validated. Once validation is complete a
>> ForwardResolution is constructed using a nested JSP file which includes a
>> fragment of the desired Response HTML. This path is specified in a Stripes
>> layout component.
>> 4) Response in browser is a form HTML fragment with expected field
>> validation errors rendered.
>>
>> The relevant debug output is:
>>
>> DEBUG [net.sourceforge.stripes.controller.UrlBindingFactory] - Matched
>> /WEB-INF/components/signInForm.jsp to [/]
>>
>> Has there been a change in Stripes 1.5.1 that would cause this behaviour?
>
>
>
> --
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
>
> ___
> Stripes-users mailing list
> Stripes-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/stripes-users
--
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com___
Stripes-users mailing list
Stripes-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/stripes-users
