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 gunter...@gmail.com 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 jsp:include 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 mtyrr...@homeaway.com 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
