This document describes all the significant changes made between 1.1/2.0 and 2.1.
We have introduced a new mechanism for creating a hierarchy for elements. Now you can make one element dependent from another, which means that:
- actions witch dependent element properly highlight parent element's menu item
- dependent element's methods have access to parent admin element and the parent object instance, which can be used in datasource / datagrid / form building or view template All currently existing admin elements have received a dependent version of themselves for your use. Also, you can easily create your own dependent elements by simply implementing the DependentElement
It was a natural consequence of this class and now this option is by default true.
Previously these options only prevented relevant buttons or batch actions from being displayed. This has changed, so:
a) Form elements with "allow_add" option set to false will throw a not found exception if you try to open the page form without supplying the ID parameter in the request.
b) Elements implementing interface Admin\CRUD\DeleteElement with option
"allow_delete" set to false will throw a \LogicException during form submission.
Deprecated inconsintent service definitions and parameters for ResourceRepository and Display contexts
All context services follow the naming convention: admin.context.<context name>,
except for resource and display contexts. These had their IDs changed and the old
versions are only aliases now, pointing at the new ones. Table below shows the
changeset:
| 1.1/2.0 | 2.1 |
|---|---|
| Deprecated value | New value |
| %admin.display.context.class% | %admin.context.display.class% |
| %admin.display.context% | %admin.context.display% |
| %admin.display.context.request_handler.class% | %admin.context.display.request_handler.class% |
| %admin.display.context.request_handler% | %admin.context.display.request_handler% |
| %admin.resource.context.class% | %admin.context.resource.class% |
| %admin.resource.context.form_builder.class% | %admin.context.resource.form_builder.class% |
| %admin.resource.context.request_handler.form_submit.class% | %admin.context.resource.request_handler.form_submit.class% |
| %admin.resource.context.request_handler.form_valid_request.class% | %admin.context.resource.request_handler.form_valid_request.class% |
| %admin.resource.context.form_builder% | %admin.context.resource.form_builder% |
| %admin.resource.context% | %admin.context.resource% |
| %admin.resource.context.request_handler.form_submit% | %admin.context.resource.request_handler.form_submit% |
| %admin.resource.context.request_handler.form_valid_request% | %admin.context.resource.request_handler.form_valid_request% |
Instead of throwing an exception, a warning message is displayed when no elements have been submitted in a batch action.
There were two instances, where Manager class was being typehinted instead of ManagerInterface. Now the latter is being used in both cases, which were:
So if this was an issue for you, it no longer should be.
Element has had the setDefaultOptions method deprecated
and the configureOptions should be use instead. Currently, it calls the old
method to save backwards compatibility.