It is not sufficient to just check whether all required elements are being
submitted. We definetely need to check whether the submit button was
pressed. But doing this and providing a standard button with a static name
simultaneously will produce conflicts if forms are using the same action
urls. To fix this, we'll add an additional form-identification check by using
a form's name or class.
refs #5525
The redirectOnLogin function now doesn't have any predefined default.
This also leads to the behaviour that "Logout" will not redirect you
anywhere on a new login while "forcibly being logged out" (e.g. by
logging out in another browser tab) will bring you back to where you
came from.
...once you lost your session. That's the only way to do this in a
smooth way. When the server get's an unauthenticated request for a
single container, redirecting to auth/login?redir=<that-container>
was not what you expect.
Together with JS handling __SELF__ in redirection URLs this will
play fine.
refs #6935
One might not expect to get a URL with params separated by & while
this is the correct way of writing them to HTML attributes. So default
behaviour is right now that all functions return URL params separated
by &, but if you cast a URL (or it's params) to a string, & will be
used.
Additionally there are toString functions allowing you to choose the
separator "manually".
refs #6699
This function had an interesting history and seems to be a result of
missunderstanding of each others commits. Removed, as the fragment is
already there.
refs #6699
Setting an url with parameters named like form elements in a form with
method POST causes Zend to ignore any POST data because GET will be
processed with higher priority.
fixes#6806
Since we are using mainly createElement and addElement is only an alias for
createElement if no object is passed our changes to addElement can safely
be moved to createElement.
refs #5525
Form creation must not depend on specific function calls. If a forms' elements are required and missing, create them. Form::isValid() must be
able to determine whether a form can be processed or not without to rely
on a particular button value.
refs #5525
As the new auto-submission implementation does not depend on whether
a submit button was pressed or not we need another way to determine
whether a form should be processed.
refs #5525
We either demand the user to add a submit button or provide a implicit
function call to be implemented by him, adding additional elements once
the form gets rendered.
refs #5525
We eagerly waited badly for a new approach to build forms, so here it is.
Should be the best compromise between the Zend_Form functionality and
our requirements regarding automatic submits.
refs #5525