How forms are being validated should not be a task that is part of the
controller action, but should be handled by the form base class as it is
most of the time the same procedure. Now a controller action just sets
up the form to use, calls handleRequest() and acts upon its return value.
(e.g. calling handleRequest() from another form or any redirection)
refs #5525
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
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
This reverts commit 88d4262e7ca17430eb2385715f402becfc653797, reversing
changes made to 6fae333048d0ef2b95f52c8113143c79e10c4e50.
Conflicts:
application/controllers/InstallController.php
library/Icinga/Web/Controller/ActionController.php
We have to live with some badly designed forms right now. Some have
submit buttons but don't know about, others don't have such but link
to foreign controllers fiddling with the form and adding different
button AFTER the form got submitted - it's a mess.
Relaxing the submission check to "just check whether btn_submit has
a value" fixes most of this. However I do not consider this being a
solution for the long run.
fixes#6423fixes#5967
refs #6540
Implementation made wrong assumptions. A form is submitted when the
submit button has been pressed. It's value is then filled, it also
is when you're just pressing "RETURN". RETURN triggers the FIRST
submit button in a form. This way we are also able to find out which
form button has been pressed.
Current implementation is still poor, however isSubmitted works as
expected right now - and so does autosubmission.
fixes#5967
- The ActionController is now able to render a seperate detail view
- All list scripts select the currently active row from the detail view with
the 'active' class
- Autosubmit is now again attached to the onchange attribute (to prevent issues
when js can't load correctly)
- Logout is now recognized and causes a page refresh (will be made more generic)
- Add history mock for testing url changes
- Update all grids to implement the app/mainDetailGrid component
refs #4611
