RFC: Ensemble Admin

The admin is an ensemble module based on the ensemble kernel. The admin centralizes all page management and content management. The admin is based on ZfcAdmin so 3rd party modules besides the ensemble admin can form one admin interface together.

In this RFC, the two features of ensemble admin will be explained. The admin can handle all CRUD operations of pages, but the content of the pages itself (from the underlying content modules) can be managed too. The currently finished task is content management, so that will be addressed first

Content management

The content management has a few requirements:

1. Routes must be adjustable: every module must be able to provide a set of child routes to handle its own content
2. Requests must be transparent: an HTTP GET, POST, PUT or DELETE can be made and the admin will by whatever means not modify the Request object
3. Responses must be transparent: an HTTP response can be send with whatever headers, status code and body contents (like, JSON or XML) so the admin will (optionally) not modify the Response object.

With above constraints in mind, an end user can "open" a page to be managed by a module. In url terms, the url /admin/page/open/2 "opens" page #2. If this page is a text module, it can display a WYSIWYG editor. If the page is from a blog module, the page can list a number of recent articles. In the example of the latter, an url /admin/page/open/2/article/edit/3 might show an editor to modify the content of a blog article with id #3.

The tree on the left side are all links to open up that page. What happens on the inside is a Ensemble\Admin\Controller\PageController::openAction() will forward the request to the appropriate controller/action registered for that page. Therefore the admin is sometimes also referred to as a "proxy" for content modules.

The route structure can be seen as two parts: /admin/page/open/:id is a first part. The second part (eg /article/edit/:id) depends on the module. Because the module depends on the page, which is given as a id parameter in the route itself, this split is explicitly made. The second part of the url is routed in a second router. The route match of the second routing step is used to forward to the module controller. In short, the flow looks like this:

With this setup, it is possible to use custom routes for modules (prerequisite #1), the forward does not modify anything about the Request (#2) and the return of the dispatched controller is handled by the framework (so, responses can be sent back, but the view model can be rendered too, #3).

Side bar tree

Something about when and how the tree is rendered. Also a method that content module controllers have the option to turn the tree off on specific pages.

Page management

Introduction

Update page settings

Title, url, etc

Move page in tree

Drag & drop

Delete a page

Some text here

Create a page

Modules have a manifest in which they announce what kind of pages they have. Selection is presented to user.

Widgets

Admin dashboard. Per user a list of widgets is rendered. Modules can announce all their widgets just like the create-page manifest. Users have option to place them in the grid. Multi-column support, drag & drop, etc.

Perhaps the widgets can be done outside the scope of ensemble and in an extension of ZfcAdmin itself.