Item985: Switching off automatic redirects in FormPlugin by an option

We already had some problems with the redirects of FormPlugin and i now maybe have an idea for people which dont want to be redirected all the time.

The long story

I am following a plan to have all the UI operrations be done by a resthandlers ( UiByRestPlugin ). That means, that i call a resthandler, e.g. renametopic. If parameters are missing, it returns e.g. the template renametopic.myskin.tmpl ( formular ) with a status code "412 Precondition Failed" or a "200" if no data has given ( and its clear that the form has been requested ). So the form gets displayed by anything ( ajax or not ).

Now i submit and miss mandatory fields. The renametopic resthandler get called again. Meanwhile or after, as iam using the FormPlugin, the the FormPlugin evaluates that fields are missing, writing them down in a session var and "redirects" and shows the template again ( with the erros appeared ). That maybe ok for non-rest approaches or for people liking redirects, but i don't think this is a good idea for all. Lets say i make a ajax submit of that form data and make something "onSuccess: alert("Rename completed" ) ..that handler would be called if a status 200 returns. As the FormPlugin redirects first 303, then the form is fetched ( 200 ) and this is NOT transparent to ajax at all, i get a 200 even if the request has not been completed.

The short story

We need an option for FormPlugin ( bin/configure ) which does forbid any redirects. That means, the form evaluates and saves the erros in Session-Vars and the leave the whole process happen. What the restHandler or core will show in the end ( which template or whatever ) is up to them. This gives a much better control over rest and over the whole UI process.

I would like to patch the FormPlugin that way. Is that ok?

-- Eugen

This should be changed to a STARTFORM attribute.

-- ArthurClemens - 12 Feb 2009

I'm guessing that no, its not OK.

as Arthur says, it should be a STARTFORM param, not some weirdly named element.

-- SvenDowideit - 14 Mar 2009

Implemented and released

-- EugenMayer - 16 Mar 2009