Basic concepts
The system is db-centric and very relation-centric. What this means is that interfaces are driven by both database tables and their relationships.
Furthermore, when producing User Interfaces (UIs), the engine reverse-engineers the current table and it's associated Children (not its parents!). This is to give some constrained form to our rendering engine. Data can be drilled from top to bottom, only. This also serves to impose security constraints "going down the hill".
Relationships
What is a parent-child relationship, in a relational database context ?
In our engine, we define a parent as a single-item record, and children as multiple records from a relation. This adds to our set of constraints in that many-to-many relationships need to be rendered in a different form, and they normally should from our analysis.
So, we define the following types of relationships;
one-to-many, your typical "normalized" relational relationship
composite one-to-many relationships based on multiple fields (ie; composite keys, this differs from general DBMS systems in that we support composite keys in app-level constraints.)
Grab bags (many-to-many, as editable drop downs or category bags)
As we detail and revisit the e-Commerce structures, we'll come across typical table-joins to generate product matrices, price tables and so on. Those are more representative of many-to-many relationships.
Basic state views
These views form the basis of the engine.
And from the above graphic, you can see how a Listing view can be generated (as a child view) in the View/Edit (& Delete) interfaces. This recursive factor is the basis for our UI rendition engine, making it possible to display Children objects.
User Flow in state Views
In order to resolve some egg&chicken problems in the rendition of our views (it is after all, our 5th or 8th iteration? I stopped counting), we had to come up with some ingenious constraints. The issue was arising from proper user flow when drilling through records, it became possible to get "lost" in the flow of things quite easily (from a user perspective). So, we've introduced this constraint to better the user flow; that is; when rendering a Listing in any View/Edit/Delete interface, that any actions would be rendered in a popup window. (Ah-ha! How ingenious!) So, the result state views diagram would look a bit more like this:
What this means, is that when a user is inside a popup, completing an action such as an Insert, Update or Delete, then the User Interface will signal the opening window for a refresh of the specific data-set, and close the current popup window (on success). If an error occurred, then the window remains open and an alert message is displayed in flashy red.
This simple hack allows us to popup detail windows in parallel, the end user can maintain such a detailed screen opened on the sideline, and return to his system to source other records. At the end of the day, this tweak allows us to effectively use copy&paste between different records, when needs be.
Different view types
Beyond the basic state-views, we further define Listing views as the following;
List views
| Regular listing | Our most standard listing style; based on Bootstrap's table components. |
| Card deck listing | A presentation based on Bootstrap's own card-deck componentology |
| Calendar view | A listing organized around a Calendar user interface, usually focused on the current date by default. Listing data is then organized on a daily basis. As currently used in the Project-Time sheet module. |
| Dashboard view | A shorter version of the regular listing, meant to represent a subset of actionable objects to be presented in Dashboard interfaces. Dashboards are meant to present a "smaller" component, and sometimes filter out gunk as well, therefore it became quite useful to distinguish it from regular listing views which are more complete in general. |
Edit views
Edit views are currently limited to our original p-child types. In the future works is a set of different edit styled views such as;
| Regular | the current Edit views with parent-child object relationships (all children as List views) |
| Invoice-style | a souped-up Edit view for generating quotes, order purchases, orders and fulfillment stacks. Because this type of form requires a specialized form of mathematical aggregate in the UI. |
| Content-Editable | Based on our integration of Content-Tools within our own engine, we're working on encapsulating this form of presentation for database records. Currently this allows us to build the Blog user interfaces, and is currently being worked into our online Product Catalog module. |
Read-only views (what we call a "View" in the diagram above) is just an Edit view with all the fields turned to read-only. Using simple access control parameters on each table, it is possible to reserve Edit privileges to a higher level of users. By default, if a user has access to List objects, but not Edit, then they might still retain View access on individual items. Mind you, it is also possible to set permissions to List, but not View,Edit or Delete, to generate non-modifiable, and non-actionable listings. (For example; log entries are a good candidate.)
Delete views
Delete views are the same as our regular View/Edit view, because we apply our data constraints at the application level, every deletion comes with a confirmation screen where we also present the objects to be deleted through Cascading relationships. Actual deletion occurs through a back-end/ajax call (like all our insertions and updates, as a matter of fact), and upon success the user is returned to the original listing where the Delete operation originated.
Relationships; how it all ties together
Currently we've minimized the amount of variability in our Relationship management system for the introductory period. This is a feature we feel the general public won't be comfortable with at first, but its a necessity for our architecture of a usable system. Relations are the basis of a relational database after all.
Our interpretation and implementation (there's no other words for it) of relationships is the crux of our rendering, and reverse-engineering, engines. Normally a good database administrator (expert ones most probably), will understand the logic behind relationship building and usually will make an effort to "normalize" their databases before production use.
The act of "normalizing" a database is basically a mathematical exercise where we'll evaluate the types of relations between tables in order to eliminate ambiguities, double-paths, unnecessary references, and turn many-to-many relationships into one-to-many-proxy-many-to-one. Typically this requires some form of database-administration training to accomplish. Our engine attempts to encapsulate this notion through our constrained logic, and careful model packaging for community distribution.
Skeleton works
Our database engineers have been busy at conceiving a "Universe" of database tables that all interlock together as a whole. The goal being to setup the necessary relationships, foreign keys and logic constraints -for- the end user. The engine allows editing tables and fields at will, but with some reservations (our constraints) when it concerns primary keys, indexes and system-reserved fields. Only a trained database administrator can define and manipulate these reserved fields, normally.
The engine comprises a set of base tables which cannot be directly manipulated by end-users, and with good reasons. These are the tables that manage Users and their access rights. Furthermore, Groups is also bit of a reserved table for its group access rights management. These tables are the result of 20 years of Internet experience running safe authentications and certifying year after year the internal methodologies. And since most of the certified auditing depends on proper user administration, these have been sectioned off-limits from the start.
Beyond user and permission tables, we have the engine's own data tables which stores Model, Table, Field, List and other details. (Honestly this grows on a regular basis). These tables are as well off-limits to end users. We had attempted in the past to integrate the said-engine tables in the engine's UI, but our past experiences were stained with little failures making this endeavor a bit troublesome. We're currently capable of rendering the engine's tables, but without the additional layer of JS-logic that sits on top of the administrative interfaces, the knitting is proving a bit difficult at this point in time. So, again, just a set of tables reserved for the engine itself. Populating these tables is done through the myriad of facets introduced in the User Interfaces anyways.
So, our skeleton currently provides the basis of a relational model, allowing a true plug&play of modules, models and tables. End users can still expand and modify their own user interfaces (expanding on the underlying data table's structure as well), but always remain constrained from touching anything that could actually break the relational model. This is our kung-fu.
Through same said-kung-fu, end users can also import community models and/or modules and tie them in their system seamlessly. In general, we only provide a "skeleton" that can be customized, end users have to put in some click efforts to further enhance their structures through the User Interfaces themselves.
Database table nomenclature
In order to maintain a clear separation of duties and avoid bottles of aspirin, all our tables are named following this convention : MODULE_tablename. Follows is a synopsis of the existing table spaces;
SYS_* System tables, SYS_User, SYS_Group, SYS_Group_Users, SYS_Session, SYS_Site, etc.. These are the System-Reserved tables. They cannot be manipulated (easily) because end users would run the risk of breaking the OWASP compliance status.
DBUI_* Database-UI tables; DBUI_Table, DBUI_Field, DBUI_Relation. These are the Engine-Reserved tables. End users definitely cannot manipulate these tables, as it would incur changes in the rendering engine itself. Reserved for our team of engineers strictly.
SIA_* Part of our Service Infrastructure Administration skeleton; it provides objects such as Project, Timeline, Tasks, Notes, Tickets and such. These tables are totally expandable. (They also come with a module set integrated with a calendar view and some nifty upcoming invoicing features).
STORE_* Part of our e-Commerce infrastructure, these tables describe a Catalog, Products, Services, Categories, Online customers, Carts, Online orders and some more.
ERP_* Part of the Enterprise Resource Planning infrastructure, it allows for the management of Processes, Resources, Inventory, Worksheets, and more to come.
Blog_* Bit of a stand-alone module, since it can be used on its own, or combined with many other modules. Blog tables include Blog and Blog_Categories. The Blog category classifications are a perfect example of a many-to-many relationship (a category can be assigned to many blogs, and many blogs can be assigned to the same category). So, our User Interfaces encapsulate this relationship as a "Grab Bag". Our Blogs come already built with their editing modules derived from Content-Tools with an amazing wysiwyg interface.
CMS_* Content Management System tables. These are normally tied to web page rendition, manipulation and administration. Our system has its origins in simple CMS, and is now an hybrid of our CMS and db-UI engines. CMS basically allows website administrators to configure language strings, content and medias to fit different language models. CMS tables include Pages, Strings and different constructs for the rendition of websites in general.
SEO_* Search Engine Optimization tables. These are paired with the CMS tables to manage the SEO headers that go with the generated content in different web pages, under different languages. Normally focused on "Internet" web pages in particular (we don't integrate SEO with Intranet or Extranet sites, since their content is normally password protected).
Bot_* Part of our Infrastructure & Automation engine, these tables are currently system-reserved tables distributed as part of our Automation Module. They currently serve to administer Bots executing under scheduled environments like Cron or Task Scheduler. The Automation engine is a parallel project integrated through its User Interfaces in this project. For more information consult http://www.cryptochocolate.com/.
Node_* Also part of our Infrastructure & Automation engine, these tables serve to inventory bare-metal and virtual server instances along with all their "componentology". Servers are setup with basic reporting scripts, executed through a Cron or Task Scheduler environment, or in the boot scripts, to report their local monitoring values. These tables are currently under heavy work, being adapted to certification processes such as SOX SOC, ISO 2700x and NIST-240/800.
Importing additional data tables
Assuming that as an end user, you have access to the databases themselves, you can very well import your own data sets and integrate your imported tables in the UI-rendering engine.
Our long term goal is to tie in the ability to import SQL files into the system auto-magically. But we're still a little way from achieving this goal for the requirement of a "good & safe" engine. (Parsing data files coming from the Internet is a sensitive matter in general). Even if a end user has no ill intentions, we cannot certify or corroborate the source of data files that would be imported, and thus, there always lies the risks of importing a Trojan. For this particular reason, we're not offering self-service data imports. We foresee offering a human-supervised service for such imports though, you can get in touch with our representatives for more information.
Otherwise, this feature is only available for self-hosted versions of our engine.
Database Galore!
Our engine is not at all limited to one database. From a web server perspective; as long as the databases are available, the system can query a multitude of different databases and integrate relationships between physical databases! (This is quite unique to our system, none other can offer this at this point in time.)
So, for self-hosted versions, our suggestion is to run the engine in its own database, and maintain your existing database structures as-is, where they already sit. Our engine really only allows Rendering and Editing data in databases, all the make-up and dress-up that gets layered on top is managed through our own DBUI_* tables, as detailed above. So you can rest assured that your existing data structure won't get messed with (unless you give your users access to do it...! )
Our implementation also abstracts the database brand, we can mount against pretty much all the relational databases under the sun.