Item6008: EditTablePlugin returns to viewauth page after save
Current State: Closed
Released In: 1.0.0
Target Release: patch
does not return to normal view after saving. Take a simple table:
After clicking Save the page is redirected to
and the EDITTABLE tag is not rendered, and the saved value not updated the updated value can only be seen when reloading the page in normal
Checking the code, the generated url passed to
a view url.
- 21 Sep 2008
Could it be something in my local setup? Here it seems to work.
No problem here, but the problem persists at http://develop.twiki.org/~twiki4/cgi-bin/view/Bugs/Item6008
This happens (at least) on Mac Firefox 3.0.3 and Safari 3.1.2.
- 05 Nov 2008 - 00:01
Input from Sopan in TWikibugs:Item6008
My guess is - something wrong in Response.pm - this is new introduction in trunk. From Core.pm of Editable ==> Func.pm goes everything well, after that the control goes to Response.pm.
- 26 Nov 2008
An extra note: When it returns to viewauth the plugin does not work in that page view.
So it is more than just returning to wrong bin script. The plugin is goofed with visible EDITTABLE tags.
- 29 Nov 2008
I've checked the code, and it has nothing to do with viewauth or view. Sopan was right indeed.
What happens is that everything is set properly, but the redirectCgiQuery function does not cut the line of evaluation of rendering handlers.
For me, when we call that, we should finalize the Engine, but it doesn't look like it's been designed that way.
Could someone ask Gilmar what's the expected behavior of the
I could hack some finalize there, but I want to have his opinion.
- 03 Dec 2008
What does "does not cut the line of evaluation of rendering handlers" mean, please?
Sorry, hadn't seen your message before.
By this I just meant that one might think a call to redirectCgiQuery will do the redirect right away.
This is not the case, and in fact, a call to this function (or the redirect in Response.pm, and a few others which get piled up) simply add the direct information into the headers.
Root cause of this bug was that these headers were being over-written by another call later on in the chain. This is what I called the "line of evaluation of rendering handlers". The fact that each registered handler is called in turn, for each possible handler "state".
By cutting it, I meant doing the redirect right away.
After discussing with Gilmar it seemed not the desired way to go, thus I just fixed the call that's used to set default headers, so it doesn't over-write headers that have already been set.
Hope that's clear enough, otherwise, see my commit
- 10 Dec 2008