I have a web dev question for a relative newbie.

I’m implementing a multi-step form with server-side validation (and client-side, but the server side bit is important)

It seems like my options for each step are: post to the same page as I’m on, validate and then redirect to the next step if ok, or post to the next step and then redirect back if validation fails.

Is it only me who feels Slack Web interface very slow lately (last several days)?

Either way, I’m basically stuck using either GET parameters for all the data or a cookie-based session, since I can’t pass anything else via the redirect. Are there any other magic solutions I’m missing?

App seems to be much more responsive.

cfleming: I did something like this with POST and hidden form fields that prefil for the next step

@dottedmag: Not sure, I only use the app.

@pxlpnk: Right, I’m doing that, but then how does the validation work?

dottedmag: the app takes ages to load with all this organizations

(disclaimer: did that in rails) we just render the old page again with the prefilled input forms

@pxlpnk: But web interface is taking ~1 second to register a keypress for me.

Ok, but say I have http://myapp.com/step1, /step2 and /step3

User submits on /step1, does the form post go to /step1 again, or to /step2?

the POST goes to step1. if that is valid I render step2 page, if invalid I render step1 page

Ok, but then the user gets the step2 page under the step1 URL, right?

its not so clean as I wanted it but the whole thing is rather painful already as it talks to 2 3.party services and a DB

cfleming: unfortunately yes.

Right. It seems like none of the options are very clean here.

Does that interfere with the back button? I guess not, since the browser history should be a list of URLs and form params.

i.e. if the user goes back from step1 with the step2 params to step1 with the step1 params, that’s probably ok - it’s not like bookmarking the middle of a wizard is very useful.

Which makes me think that perhaps doing all the pages under the same url, like /payment or whatever isn’t such a bad idea.

does this help? https://en.wikipedia.org/wiki/Post/Redirect/Get

cfleming: ahh you are also modelling a payment flow? 😄

@pxlpnk: Maybe

😛 yeah that whole topic is rather annoying. I actually wanted to do it in a one page thing, but our UX team was against this

Yeah, it’s much more tricky than I expected.

I’m tempted to just use reagent and be done with it.

It seems like it should be a solved problem by now, I guess most people just use the session.

@mcgivernsa: I’ll take a look, thanks

that page only describes the browser flow, I see above you were looking to avoid sessions or GET params, so maybe it doesn't help too much 😕

Yeah, it seems like you need one or the other because of the redirect, you can’t pass POST params

@cfleming Don't use get for post things, no matter the topic. I have no opinion about sessions, but, why not go with the hidden field approach? You can just store a custom format (edn for example) there with the data from the former steps and be done

@sveri: but that doesn’t help the validation case.

client or server side validation?

Server

hm, on every request you have all the data you need on the server, why cannot you validate then? sorry for asking again, I just don't understand it right now

So the user submits step1

That posts to either /step1 or /step2 depending on how you implement it.

Say we post to /step1

Then you validate. If the validation fails, then you render the /step1 page and all is good, otherwise you render /step2, and get the step2 page under the step1 URL.

If you initially post to /step2, and your validation fails, then it’s the same case - you re-render step1 under the step2 URL.

could you use ajax to post to e.g. /validate/step1 and then set window.location in the callback?

@cfleming:

@swizzard: Sure, I was trying to do a simple flow, and just couldn’t believe it was this complicated.

yeah 😞

Ah, now I get it. What I usually do is to call (step2 [params] which then renders the site. Not sure if it's a bad practice or not

it's not really that simple though, is it? the result of the POST to a single URI (doesn't matter which) can be either step 1 or 2

but you don't want to redirect, and you want the URI to be representative

@mcgivernsa: Exactly.

It seems like I might as well do the whole flow under the same URL, like /payment or /purchase or whatever

another option would be to use the history API to increment the step number if the response is valid - I think this would work properly with the back button

And always post to the same place.

but yeah, just a single page probably makes most sense if you're cookieless

s/page/endpoint

Right.

I don’t have a strong need to be cookieless, but given all the EU cookie faffing about it seemed simpler to avoid them if possible, and it’s not like I’m trying to do anything super complicated.

> The ICO has said that it isn't good enough to just re-implement the tracking some other way outside of cookie storage.

http://www.theeucookielaw.com/ (not an official site)

It’s actually making a pretty good case for a SPA

Where I could avoid all of that.

I need JS enabled anyway for some client side validation.

mcgivernsa: thanks

Huh, today I learned about the 307 status code: http://programmers.stackexchange.com/a/99966

Although it seems you get a mandatory “do you want to post your data again” message

The advantage of POST + redirect is that if your users refresh the page they won’t be prompted to resubmit the form values

But yeah, personally I’d use an Ajax / SPA approach for this

@timgilbert: Right, unfortunately the POST + redirect only works if you’re using a session.

I’m going to prototype an SPA to see if works better, I think it will.

Yeah, without a session your best options are hidden form fields or cookies, which are both not very good