Form Widget → Redirect → Summary Widget

2025/09/17 8:26 AM

How would you handle a situation where you have a form widget that displays a form on one page, and after submission, the user is redirected to another page with a different widget that should show a summary of the submitted data?

The main challenge is figuring out how to pass the submitted form data across the redirect so that it’s still available on the next page. How would you implement this in XbyK? Have any of you actually implemented this?

I’m struggling to find a solution that doesn’t feel like a workaround. My real use case is more complex, but it can be simplified to the example above. I did come up with a working solution, but I’m not happy with it, it feels quite hacky. It involves using async event handlers, generating a custom form submission GUID, passing that GUID through the response headers of the FormSubmit request, intercepting the HTTP request on the client side, storing the GUID in session storage so it survives the redirect, and then, on the target page, reading the GUID from session storage and making a HTTP request to a custom controller to fetch and render the submitted form data. Pretty messy.

Tags:
Form Builder

Answers

2025/09/17 3:06 PM

Here's some ideas:

  • Post-redirect-get using TempData is an option, but this requires a true form POST and not one initiated by JS.
  • Store the data in a cookie that will "self-destruct" when read (have your cookie reading function delete the cookie after reading).

To intercept the HTTP request on the client side, did you patch the client window.kentico.updateableFormHelper.submitForm method with your own that lets you handle the request and response and configure (using a customized Form Widget or some page-embedded state) where to redirect to? You could pass the GUID or some opaque identifier in a query string as well - that way if the user refreshes the page they are redirected to they will still see the message.

2025/09/18 12:37 PM

Thank you, Sean, for your response. It made me revisit the implementation and come up with a fresh approach.

My initial (and preferred) solution was to use a query parameter that I could append to the redirect URL. In legacy Kentico versions, this was easy thanks to macros. In XbyK, however, there doesn’t seem to be such a flexible way to set up a dynamic value for the query parameter in the Form widget properties. You actually suggested something similar in your reply, and I’d be keen to learn how you would do it. Specifically, where is the right place to safely inject such a query parameter?

Thanks also for pointing me to the window.kentico.updateableFormHelper.submitForm method. I don’t think patching or manipulating it is a good idea for maintenance reasons, but reading through its implementation gave me more insight into how form submission and redirects are handled. I noticed that the action attribute of the form tag contains a URL with a query parameter holding the redirect URL. I tried manipulating that to inject an additional query parameter, but the form submission failed when I did so, most likely due to security concerns, which makes sense.

You asked about HTTP request interception on the client side. I did experiment with this using a separate “observer” that tracked requests and checked whether they matched the FormSubmit URLs, without relying on the window.kentico.updateableFormHelper.submitForm method.

Finally, I gave the cookies approach another try, as you mentioned. I had tested it before, but something wasn’t working quite right. Since I had changed the overall implementation quite a bit, I decided to revisit it, and this time it worked. In the end, I was able to simplify the process, move most of the logic to the server side, and eliminate a few unnecessary steps.

Here’s the current flow:
Form submission → Event handler → Create GUID and store it in both the form submission and a cookie → Redirect → Summary widget reads the cookie, fetches the form submission server-side, and renders the data. I added a couple of extra security measures, but that’s the core flow.

So, I was able to simplify things. This could make a good blog post topic since it’s not an unusual scenario. I also think there’s an opportunity for the product to provide better support for this kind of use case.

To response this discussion, you have to login first.