Behaviour default views

[jaxwilko]

This PR adds default views for the following backend controller behaviors:

• FormController
• ImportExportController
• ListController
• ReorderController

Backend\Classes\ControllerBehavior will now automatically append their views folder to the controller's view paths allowing them to provide fallbacks for any views required by the behavior.

The create:controller command will now no longer generate the views by default unless --stubs is also passed and the --sidebar flag is replaced with a --layout=(standard|sidebar|fancy) option to choose the form layout to use.

Also:

• Added appendViewPath() and prependViewPath() to the System\Traits\ViewMaker. addViewPath is renamed to prependViewPath() and is for paths that have higher priority than the existing paths while appendViewPath() is for paths that should have lower priority than the existing paths (i.e. fallbacks).
• Backend controllers will now automatically set their navigation context in the form of Author.Plugin as the author, $pluginName as the main menu code, and $controllerName as the side menu code. This means that you can remove calls to BackendMenu::setContext() and constructor overrides in your controllers if they follow that convention.
• Support for passing new: true as a parameter in the request body to onSave() calls that will return a redirect to the create action
• formMakePartial(string $partial, array $params = []) to the FormController behavior that will render a partial through the controller's makePartial using the following priority list of contextual names: form_$context_$partial, form_$partial, $partial).
• Support for abort(403) to return the access denied view in the backend
• Improved handling of abort(404) in the backend
• Improved styling of disabled fields in the fancy form layout
• Improved styling of file generated / updated status message in scaffolding commands

To Review:

• Core controllers in Backend, CMS, & System modules
• Flexible form buttons (Extract create/update form buttons into their own partials #1352)
• Winter.Blog (Remove unnecessary controller customizations / support Winter v1.2.8 wn-blog-plugin#72)
• Winter.Forum (winter 1.2.8 support wn-forum-plugin#17)
• Winter.Location (winter 1.2.8 support wn-location-plugin#7)
• Winter.Notify (winter 1.2.8 support wn-notify-plugin#3)
• Winter.Redirect (winter 1.2.8 support wn-redirect-plugin#23)
• Winter.Sitemap (winter 1.2.8 support wn-sitemap-plugin#22)
• Winter.SSO (winter 1.2.8 support wn-sso-plugin#15)
• Winter.Test (winter 1.2.8 support wn-test-plugin#22)
• Winter.Translate (winter 1.2.8 support wn-translate-plugin#95)
• Winter.User (winter 1.2.8 support wn-user-plugin#57)
• Add support for this to the scaffolding commands

[mjauvin]

I've been wanting to do this for ages...

Great work!

[jaxwilko]

@LukeTowers @mjauvin any thoughts on my changes to ViewMaker?

[mjauvin]

@LukeTowers @mjauvin any thoughts on my changes to ViewMaker?

I like it @jaxwilko, as long as it doesn't introduce BC issues, which it shouldn't.

[mjauvin]

@jaxwilko @LukeTowers I'd like to add the possibility to not show the Trash (delete) button in the _toolbar.php formController partial if a property of the controller is present (e.g. $hideTrashButton). I've always found that button can be mistaken for the relation manager delete button (i.e. one selects an item in the relation manager and instead of clicking "delete relation item" one clicks the form "trash/delete" button.

What do you guys think ?

diff --git a/modules/backend/behaviors/formcontroller/partials/_toolbar.php b/modules/backend/behaviors/formcontroller/partials/_toolbar.php
index d4929319f..f07addfa4 100644
--- a/modules/backend/behaviors/formcontroller/partials/_toolbar.php
+++ b/modules/backend/behaviors/formcontroller/partials/_toolbar.php
@@ -65,15 +65,17 @@ class="btn btn-default"
         >
             <?= e(trans('backend::lang.form.save_and_close')); ?>
         </button>
-        <button
-            type="button"
-            data-request="onDelete"
-            data-load-indicator="<?= e(trans('backend::lang.form.deleting_name', ['name' => trans($modelName)])); ?>"
-            data-request-before-update="$el.trigger('unchange.oc.changeMonitor')"
-            data-request-confirm="<?= e(trans('backend::lang.form.confirm_delete')); ?>"
-            class="wn-icon-trash-o btn-icon danger pull-right"
-        >
-        </button>
+        <?php if (!$this->hideTrashButton): ?>
+            <button
+                type="button"
+                data-request="onDelete"
+                data-load-indicator="<?= e(trans('backend::lang.form.deleting_name', ['name' => trans($modelName)])); ?>"
+                data-request-before-update="$el.trigger('unchange.oc.changeMonitor')"
+                data-request-confirm="<?= e(trans('backend::lang.form.confirm_delete')); ?>"
+                class="wn-icon-trash-o btn-icon danger pull-right"
+            >
+            </button>
+        <?php endif ?>
         <span class="btn-text">
             <?= e(trans('backend::lang.form.or')) ?> <a href="<?= Backend::url($formConfig->defaultRedirect) ?>"><?= e(trans('backend::lang.form.cancel')); ?></a>    
         </span>

[LukeTowers]

@mjauvin if we make it configurable then it should probably be through the form config and it should also disable the Ajax handler. Could we change the delete button to make it more obvious what it does instead?

[mjauvin]

@mjauvin if we make it configurable then it should probably be through the form config and it should also disable the Ajax handler. Could we change the delete button to make it more obvious what it does instead?

Can we do both ?

<?php if (!isset($formConfig->hideTrashButton)): ?>
    <button
        type="button"
        data-request="onDelete"
        data-load-indicator="<?= e(trans('backend::lang.form.deleting_name', ['name' => trans($modelName)])); ?>"
        data-request-before-update="$el.trigger('unchange.oc.changeMonitor')"
        data-request-confirm="<?= e(trans('backend::lang.form.confirm_delete')); ?>"
        class="wn-icon-trash-o btn-icon danger pull-right"
    >
    </button>
<?php endif ?>

[LukeTowers]

@mjauvin why do you want to disable the button / the handler separately from each other? We might also want to take inspiration from the RelationController's approach to managing the available buttons (see toolbarButtons on https://wintercms.com/docs/v1.2/docs/backend/relations) if we go down this route. Either way, I'm thinking we should make that a separate PR so that we can review it without blocking this one.

[LukeTowers]

@mjauvin thanks for all your work on this, it's made it much easier to review. I'll made it through half of the related PRs today, should hopefully be able to finish it up during office hours next week. Many thanks to @jaxwilko for the improved abort() handling in the backend as well ❤️