-
Notifications
You must be signed in to change notification settings - Fork 5
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
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).
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
- 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 is 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.
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).
The CRUD portal should visually implement the AdminLTE design template, instead of the default one. This is optional, though. But some of its functionality is desirable.
AdminLTE has an open source version which is available here: https://github.com/almasaeed2010/AdminLTE
The ASP.NET variant of Evolutility provides basic user authentication functionality. I don't think the other two variants have such functionality implemented.
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.
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.
Copyright © 2019 Eitan Blumin. All Rights Reserved.