Moving the “do” parameter from URL to POST data is huge BC break. Problems are
- setAction() to another page with different presenter doesn't work, destination presenter throws exceptions – says something about unknown signal receiver.
- forms which are handled through ajax depends on “do” url. We have a lot of forms which have this ajax functionality and depends on “do”.
- there is a new hidden field and component, which breaks functionality of some iterations over form elements
We have a lot of forms of these types and rewrite these for such a change is huge work and cannot be automated like string replacing. All of these cases must be solved manually, it takes a lot of times and money. There is also impossible to find these cases quickly.
This change isn't also clearly promoted in the migration articles as huge BC break, but as new behavior (https://doc.nette.org/…igration-2-2).
So I request to return back the possibility of “do” url actions for the forms. It can be configurable and optional. POST data option can be default. Please.
If it's isn't possible, can some nette experts propose us some patch or workaround for returning back old functionality to 2.2? It's very welcome, we cannot migrate to 2.2 because of this break. We are disappointed, because migration according mentioned article seemed to be very easy and BC compatible. It really was, but this one breaks our migration.
It seems that revert patch isn't very complicated. Is it all? Are there any related commits after that which change old functionality?
If it isn't very complicated, returning old option back to framework at least as “deprecated” for 2.2 is much better solution then patching myself. Most of changes in 2.2 are with nice BC handling (class alias, deprecated exception), but this one is removed without simple solution to return it back.
- Ondřej Mirtes
- Member | 1539
In my testing, passing ‘do’ in the query string when manually submitting forms with AJAX still results in firing off the attached events. I don't see why it should not work based on this commit. It does not break the existing functionality, because the original $params array is based on the parameters from the request – which include query string parameters. So the ‘do’ in the query string still submits the form.
- Ondřej Mirtes
- Member | 1539
I realized why it does not work for you and why it works for me. You are sent to the correct action based on the address you're passing to setAction(). But what's different from 2.1 is that Nette automatically appends the ‘do’ hidden input to the form and that's also sent with the POST data. So although your request correctly arrives to the right presenter, Nette sees the ‘do’ parameter and tries to create a component in order to submit it. And since this component does not exist in the target presenter, it throws an exception.
This approach works for me because I have the component with the same name in both presenters. I use this approach to create small presenters in my single page application. One (“root”) presenter renders all the forms and other presenters handle these submitted forms.
I recommend you doing the same because you make use of the validations Nette forms offer you for free that way.
Our ajax handling is different, it takes url from the form action, so it takes new url in 2.2, not old with “do” and send via POST some values, not all values. New behavior in 2.2 breaks this functionality. In 2.1 it works, in 2.2 doesn't.
regarding setAction() and destination presenter:
Thank you for the explanation, it means that this change is really BC break, and we need to find all these places with setAction() and correct these. It take huge time and effort.
As I mentioned, it should be deprecated in 2.2 but not completely replaced, this is reason for this request.
@blindAlley Why do you use
Nette\Forms\Form? For the component tree?
In 2.1, when you set form action manually, you dropped
parameter from URL which means, that form component never received POST data.
And validation never run. In a result, you broke the component “life
The right way is receive POST data in
onSuccess event and then
propagate them. I don't see your use case, but it may lead to security problem
In 2.2, the
do parameter is moved to POST. You can still set
form action manually and you do that. I don't see your source code, but is it
problem search for
do field and use it in AJAX routine? The same
with elements iteration.
Milo, all your suggestions are helpful, thanks.
Maybe our code isn't perfect, but as I mentioned, this change in 2.2 has
broke our applications (we have many nette driven apps) in many places, and it
isn't simply to find these places and make simple and quick corrections. E.g.
ajax form silently doesn't work, it produces no warnings/exceptions.
It's huge BC break for us and we cannot migrate to 2.2 as we wanted. Primary reason for this request is better BC in kind of other changes in 2.2.
OT: When you mentioned usage of setAction() with Forms\Form instead of UI\Form, I don't see reasons for setAction() in UI\Form at all.