Features List: All New Features
The following features are NOT implemented by Evolutility (and don't seem to be planned either). But we'd like to implement these features in our own project.
The features are sorted by priority, from most-desirable to less-desirable.
In addition to the contextual "edit" and "delete" buttons seen in the List view of Evolutility, we'd also want to implement a "clone" button, which would have the same functionality as the "add" button, except the fields would be pre-filled with the data of an existing item (for which we clicked on "clone").
Each form can have, in addition to its normal CRUD functionality, also a set of customizable "action buttons".
Each such an action button can be either one of the following:
- Regular HTTP link
- Custom database T-SQL command
- Parameterized database T-SQL command (will use a modal dialog to set parameter values before execution, and/or use pre-configured "default" values)
- Custom client-side function in Angular/React (if this feature proves too complicated, don't worry about it. It's not priority).
Action buttons could be placed either at the top of the page (at the toolbar), and possibly even be formatted as a hierarchical menu, or as contextual buttons per each row in the List view (right next to the Edit/Clone/Delete buttons).
For example, the "Cities" button in this screenshot from Laravel CRUDBooster:
The following "global" settings should be easily configurable:
- Site Branding (various options to allow admins to personalize their CRUD portal)
- Site Name (to be used as browser tab title)
- Site Public URL (for use in e-mails and such)
- Color theme (for example, use the themes provided by AdminLTE)
- Layout type (for example, based on AdminLTE layouts)
- Favicon (with an ability to upload a new one)
- Toastr Notifications Style Options
- Footer text
- Security Settings
- Toggle Anonymous Registration
- Toggle User Profiles
- Manage roles and permissions
- Configure SSO integrations
- General Settings
- Database Connection String for the data models
- Database Connection String for CRUD configuration tables (i.e. EvoDico tables)
- More (TBD)
Some of these settings should be database-independent, for added security. Perhaps in an editable json file or web.config or something like that.
Other than the CRUD functionality, we'd also like to implement the ability to create custom pages for miscellaneous uses.
These pages would have no special dynamic functionality other than being able to change their slug path (to be used in dynamic routing for easy-to-use hyperlinks).
There would be 3 different types of custom pages:
These pages would be modified using a rich-text editor (i.e. wysiwyg).
Their contents would be saved inside the database.
These custom pages would embed an iframe as the content of the page.
Only the path to the iframe content would be stored inside the database.
These are not so much "custom pages" as it simply is a sort of blank "template" file that would be provided as part of the portal. This "template" file would only contain the code necessary to display the header and footer of the website. Instead of page content, it would only have a temporary placeholder.
The portal owner could then copy this blank template file, and put anything they want inside the content placeholder of this page, and change anything else they'd like.
The new file can then be saved under a new name, and a custom link would then point to it.
The navigation sidebar would be fully configurable, including hierarchical links.
Each link can either point to one of the forms, or to a custom URL.
If a link points to a form, it would automatically be visibly set as "active" when its form is opened.
If a link points to a different page, then it would automatically be set as "active" when that page is viewed.
Also, a navigation link may optionally have a setting telling it that its target should be opened inside an IFRAME object. In this case, clicking on the navigation link will open a special page which would receive the navigation item ID as a parameter, and this special page will open the designated target inside an IFRAME window. This would be a good feature for opening resources outside the portal (for example, third party web apps such as Sharepoint, or SQL Server Reporting Services).
A navigation link can be "activated" by more than one form (in case there are forms that link to each other, and/or if there's a hierarchical relationship between them).
Example:
loadSideNav() recursive function in CRUDE-ASP.
Ideally, the interface to manage the navigation menu should be an interactive tree view with draggable nodes. For example: http://akveo.com/blur-admin-mint/#/components/tree
The CRUD portal should visually implement either the AdminLTE or Blur-Admin design template (or something comparable), instead of the default one. This is optional, though. But some of its functionality is desirable.
These Admin templates have an open source version which are available here:
https://github.com/almasaeed2010/AdminLTE
https://github.com/akveo/blur-admin
The ASP.NET variant of Evolutility provides basic user authentication functionality. I don't think the other two variants have such functionality implemented. But the other crud generator do (serenity for example).
Either way, what we want is this:
Obviously not any visitor should have the ability to modify the forms and data, so some sort of security framework would need to be implemented. Logging in, registration, usernames, passwords, profiles, browser cookies, the whole shebang.
Initially, we'll only need to determine whether the visitor is an "admin" or a "moderator" or a "visitor", which would determine whether they can configure and create forms, or just edit their configured content, or just view the data, respectively.
After that, it would probably be a good idea to implement custom "roles" where you can set which roles can access which form, and which operations they can perform on them.
For example, privilege management in Laravel CRUDBooster:
Ideally, it would be best to also be able to use SSO services such as Office 365, Google, Facebook, Twitter, etc. But that would be much harder to implement due to the SSL and OAuth requirements, creating and uploading certificates, etc.
In addition to panels and tabs as they are implemented in Evolutility, I think it should be fairly easy to implement additional methods of grouping sets of form fields. Specifically:
- Wizards (each group represented as a step in the wizard)
- Accordion grouping
Examples:
This is obviously super advanced and may be reserved for premium licenses or something... But basically the idea is to let administrators install plugins that would extend the functionality of their portal. In essence, "installing an app". For example:
- E-commerce app (products list, cart, checkout, etc)
- To-do list
- Calendar app
- Messaging app
- Forums app
I have no idea how one should go about implementing such an ability, but I think it should technically be possible.