NOTE: this page is work-in-progress and is subject to change frequently

This page contains details about the database tables that would be a part of the CRUDE-NET project.

In this page:

• True Show of Strength
• crude.Configuration
• crude.DataSource
• crude.DataView
• crude.DataViewPanel
• crude.DataViewField
• crude.DataViewQueryGroup
• crude.DataViewQuery
• crude.DataViewAction
• crude.DataViewActionParameter
• crude.DataViewChart
• crude.Comment
• crude.User
• crude.Role
• crude.PermissionSegment
• crude.UserRoles
• crude.RolePermissions
• crude.AuthProvider
• crude.CustomPage
• crude.NavSection
• crude.Navigation
• crude.FilterOperator
• crude.FieldType

The CRUDE-NET platform is very extensive and contains many database tables needed for its implementation and management. However, a true show of strength of the CRUDE platform, would be to implement the management of these tables using the very platform they're used for implementing.

In other words: Use the CRUD generator platform to manage the CRUD generator platform.

If all functionality needed for the management of these tables can be implemented using the CRUDE platform itself, that would, indeed, be a True Show of Strength of the CRUDE platform, right off the shelf.

(only exception, possibly, would be the management of the navigation menu items, which would be managed using an editable treeview control)

Also, leveraging the crud generator abilities for the administrative sections should tremendously reduce development time and effort, since we won't need to hard-code these sections ourselves.

Controls various site settings.

Each setting would have its own column in this table. Please see Site Settings for list of settings.

Exact structure and implementation of this table is TBD

The data source would be the equivalent of a connection string, defining the source server, authentication and default database. However, this table won't contain the connection string itself. This table could be managed dynamically, but the actual use of it would be by correlating the data from it with a secured configuration file (i.e appSettings.json or web.config or something equivalent). This is so that we won't save secure connection strings inside the database.

In other words, this table would contain identifiers that the controller layer would know to look for in a secure configuration file, to find the actual connection string.

More fields are TBD.

Equivalent of Evolutility's form element.

Each record in this table represents a single data model, with a single underlying database source (either a table/view or a stored procedure).

Equivalent of Evolutility's panel , tab and panel-details elements.

Panels are used to visually group fields on the screen (in edit and view modes).

Panels can also contain sub-groups of panels (for example, a panel can contain tabs, which in turn can contain more panels etc.).

Alternatively, panels can be configured as "Grid Panels" (equivalent of Evolutility's panel-details element).

Grid Panels allow for nested sub-entities within the driving entities. In other words, it allows for hierarchical data and adds the feature of master-details. The sub-entity (or detail) can be edited within the page as a grid, or by linking to another page using the sub-entity as its driving entity.

The screenshot below shows an order. The master is composed of 3 panels, one panel-details and another panel for the total.

Grid Panels cannot contain fields or sub-panels.

Equivalent of Evolutility's field element.

The data view fields represent fields on the screen, and database columns at once. It is the most used element and the element with the most attributes. Database columns hidden to the user (like the primary key of the driving table) are not declared.

Equivalent of Evolutility's queries also know as "Selections"

It is possible to add canned queries as a "Selections" button on the toolbar.

Queries are also grouped into Query Groups.

Equivalent of Evolutility's query used within "Selections".

Each dataview can have, in addition to its data displayed, also a set of customizable "action buttons".

Action buttons could be placed either at the top of the page, and even be formatted as a hierarchical menu, or as contextual buttons per each row in the datatable (right next to the Edit/Clone/Delete buttons).

After activating an action, a modal will be displayed with the text string returned as response (except for http links which would simply open the URL).

Action parameters can be configured for all action types (HTTP Link, DB SQL Command, DB SQL Procedure, JavaScript function). A modal dialog will be displayed for setting parameter values before execution, and/or use pre-configured "default" values.

Parameters for http links would be appended to the URL querystring. DB Commands and procedures would receive parameters as SQL parameters, and JavaScript functions would also receive these parameters accordingly.

Configures the set of charts that would be available for a data view.

Defines the type of chart (line, area, pie, bubble, bars, etc.) and the various dimensions as needed (x, y, z) mapped to database columns or expressions.

TBA

Equivalent of Evolutility's EVOL_Comment.

TBA

Used for authentication, registration and profiles. Equivalent of evolutility's EVOL_User. Also comparable to aspnet_Users.

Passwords are saved as one-way hash values, with a salt randomly generated per each user/password.

I'm not sure yet what's the best way to go about the extendable user's profile fields. Whether to save them in a single document column (JSON or XML), or as regular relational table columns. Also, there may be more columns TBA.

Various roles such as user, moderator, admin, and any other custom role.

Comparable to aspnet_Roles.

A logical group of site objects and sections (i.e. data views, navigation menus, etc.) to be used for setting permissions.

Mapping between users and roles. A user must be mapped to at least one role in order to have any sort of permissions.

Determines the permissions configured per each role, for each permission segment.

A table holding settings of various SSO authentication service providers (i.e. OAuth and OAuth2), such as: Facebook, Google, Twitter, Office365, LinkedIn, Yammer, etc.

I'm not actually experienced with OAuth implementation so I don't know what other fields may be needed here.

Custom pages are rich text format pages used as non data bound web pages.

Theoretically, this entity may not be needed, if one was to create a data view without any data binding, instead only using the rich text format description of the data view.

A logical "super-group" of navigation items.

Each Navigation Section would be displayed as a top-navbar menu-item.

Clicking on a top-navbar menu item would open a page with the side-navbar menu changing its contents to fit the Navigation items belonging to the selected navigation section.

Equivalent of CRUDE-ASP's Navigation.

Each navigation item would belong to a specific NavSection.

The NavUri, ViewID and PageID fields are all optional, and are mutually exclusive.

If more than one is set anyway, the one chosen will be based on the following priority order: NavUri, ViewID, PageID.

In either case, if this menu item is also the parent of another menu item, no link will be created for this item. Instead, it will serve exclusively as a parent tree node, clicking which would show or hide its sub-nodes.

Based on the Dynamic Filters solution, to be used for advanced search.

Defines a set of filter operators (equals, not equals, larger than, smaller than, in, contains, starts with...), whether they're a multi value operator or not, and their respective database expression template.

For example, the template for "starts with" is:

{Column} LIKE {Parameter} + '%'

The template for "in" is:

{Column} IN (SELECT [value] FROM {Parameter})

Shared lookup table between field types and parameter types.

Will also define which filter operators are valid for which data types, and which types can be used by action parameters.

Depending on whether this is possible in the programming language, this table may also contain information about how the data type may be implemented (various templates for the view layer, validations, etc.). If this is possible, it would allow us to very easily extend the list of data types. An alternative would be to use a standardized file naming convention for loading partial files implementing the functionality of each type.

More info about custom field types.

More fields may be added as needed, based on the programming language and implementation.