We plan to use Crispy form to enhance form layout. So we need to code a crispy helper that automatically build helper field for each Controller slot. It is not planned for the user to be able to manage help fields.

However, we may think about some "grid layout" option on slot so the user can choose if slot content takes full width or less using a grid system.

We need a dedicated view in admin to display a list of Controller entry data since the Entry admin list do not show datas because they can not mix with other Controller.

This will have to be safe with data from entry saved from previous Controller version (as seen in #3)

Controller should be able to define a custom form template and possibly also a custom success template.

Currently in Entry detail admin, the JSON data is just displayed in a textarea without any formatting, this is just raw JSON.

It would be nice to have it formatted at least as a JSON tree.

Canopy stands on internal slot definitions to build the form fields.

We don't want to be like django-fobi that did have too many options for each field types but we will probably needs a little bit of options, like with an Integer field, you would expect to set a minimum and a maximum limit from the Slot options.

Since there would be too many options to modelize from various Django form field or widget, we just can not add them all to the Slot model, so it will need to be stored as JSON.

This leads to a problem, editing JSON is not user friendly at all so we would need something to turn the JSON to virtual fields that can be humanly edited.

There is a very nice frontend module for this with json-editor library. However, it needs to be implemented properly in the Slot form.

There was a Django app for this before with django-admin-json-editor but it is stale since some years, however it may helps to implement again.

We need a lot more of Slot definitions to use in Controller form.

Here we will (soon) define a list of useful slot to make available in definitions:

• Start to enumerate useful slot fields

The controller needs to have a "published/unpublished" option so it can be disabled from front but still existing in admin without data loss, or for when starting a draft form but not finished enough to be available.

Also in this way, a preview would be useful.

This view has currently no test yet, however actually almost everything is under work so it may not very urgent yet.

But it should be done soon to start the view coverage before growing.

Since a Controller can change to add new fields, remove fields or edit field options, the saved JSON data in previous version won't fit anymore to the new Controller structure and options.

At first, the usage of entry JSON data must always be compatible with new Controller version such as it won't break the data listing.

Then we would need a safe way to upgrade data from previous controller version. For this we have added a "version" value on entry that is filled with current controller version, so we can more easily know what entries are up to date or not.

To start with this, we need to predict and choose how we manage these differences. Then we would be able to code the upgrade features. It should be at least available from a commandline since it is flawless for heavy migration when Controller have a lot of data. And maybe we could think of an Admin action, but it could be risky with huge process and request timeout.

• When a new field is added, the data must include it with a blank value (this would need a default value on definition);
• When an existing field is removed, the data must be cleaned to remove it;

This is currently just a redirect to a basic template view and it is not informed about the Controller from where it comes from.

We plan to have some Controller feature to edit a custom success message in HTML. So the success view will always need to know the Controller it comes from, this must not be lost.

The redirect way has benefit that it avoid duplicate POST on browser reload.

However it may have been useful also that success view know also the Entry that was saved with the Controller request. Without redirection (rendering success in form_valid()) would have enabled this easily. But we prefer to keep the redirect way.

Maybe we could add saved Entry reference into the user session, but it would be a security risk so it would need to be strongly thinked.