Conditionally make form GET or POST

[djay]

Currently all forms are POST which is an issue when making search forms or forms that don't change data.

I can see how to fix this in JS, but a better solution would be to select this in the form configuration itself.

https://github.com/plomino/Plomino/issues/327?source=cc

[jean]

A form method formula would work. It would function like the document title and id formulas.

What other aspects of the form should be configurable?

[djay]

why does it need to be a formula? Isn't it easier to just have GET/POST dropdown?

[jean]

Document title and id don't need to be formulas either, but making them formulas is much more flexible.

Eric thought hardcoding POST is good enough. You think choosing GET or POST per form is good enough. Someone else has a use case where it needs to be dynamic (e.g. startpage.com offers the choice between GET (for bookmarkable searches) and POST ("keeps your search terms out of the logs of webmasters of sites that you reach from our results")).

Eric thought having a document title formula evaluate once on creation is good enough. You needed a document title formula evaluated on display. In #382 I'm proposing one formula to enable extensible, static or dynamic configuration of the form.

One could have both dropdown and formula, but anyone making decisions about form method is surely able to write return 'GET' (or, in terms of #382, return {'form_method': 'GET'} or return {'form_attrs': {'method': 'GET'}}. (For single-line formulas, just 'GET', {'form_method': 'GET'}, etc. is also valid, though I prefer always using explicit return.) So I don't think it's really worth the trouble to add a dropdown.

[djay]

Yes you right it is more flexible but on the other hand it prevents a non coder from being able to make that change. One of the things I really like about Plomino is there is a good balance between what can be done without having to understand python vs advanced options for developers. I think dynamically selecting POST/GET is very much an edge case. The only reason I can see change GET vs POST is the "search form" option is selected and thats not dynamic. What I'd recommend is a drop down of "GET","POST","AUTO" (selects based on if it's a search form or not). If we really want to support dynamic then perhaps there is a 4th option for "OVERRIDE" and then on another path code can be used to work out the value. I do think it is worth it add this drop down. I think its easy for us developers to overestimate the intimidation that a code field gives to a non technical user.

BTW, your new title override is a great however it would be better for the user experience if that was an advanced option in another tab. I know it's not aptly named but since all the other formulas are in "Events" perhaps thats the best place for it?

[jean]

In principle I agree with you, but isn't GET vs POST opaque to a non-coder anyway? OK, it's useful to a javascript coder. I also agree that non-coder Plomino use is great, but there's a good deal of tidying-up needed: the line between coder and non-coder is quite blurry at the moment.

4th option for "OVERRIDE

Actually we could make it that if a formula is supplied, it governs. Move all the formula stuff off to a tab of their own and simplify the options on the first tab.

[jean]

First pass: #396 Still need tests, and I forgot the AUTO option.

[jean]

We have tests and Auto now. For AJAX calls: they should be GET, because they don't change server state. Reasons for them to be POST:

• they could be very long,
• GET parameters end up in webserver logs.

Should we have a global parameter for AJAX method? Discussion on #396

[djay]

Maybe making the AJAX the same as the form method is the safest.