Skip to content

Latest commit

 

History

History
121 lines (101 loc) · 4.78 KB

File metadata and controls

121 lines (101 loc) · 4.78 KB

CHANGELOG FOR VERSION 2.1

This document describes all the significant changes made between 1.1/2.0 and 2.1.

Introduced dependent admin elements

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

Added "allow_add" option to Admin\Crud\GenericFormElement

It was a natural consequence of this class and now this option is by default true.

Properly verified "allow_add" and "allow_delete" options

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%

Batch actions do not throw an exception when no elements are submitted

Instead of throwing an exception, a warning message is displayed when no elements have been submitted in a batch action.

Replaced Admin\Manager typehints with an interface

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.

Deprecated setDefaultOptions in favour of configureOptions in Element interface

Element has had the setDefaultOptions method deprecated and the configureOptions should be use instead. Currently, it calls the old method to save backwards compatibility.