Core 2020 currently in Beta!

[ April 2020; the SaaS part of this project has been installed under http://componentology.com and http://atrak.io, the current documentation is still totally valid, albeit from a more self-hosted perspective. ]

June 2020 release

In this rollout we're closing up some important feature upgrades and implementing an original concept of ours into atrak.io in the form of a Ghost infrastructure for multi-tenancy security and optimisations.

We've completed the card-deck interface which is an optional interface now offered in the Listing interfaces, along with a calendar view which still requires some love. The Editing interfaces have seen a major upgrade with the now-working Content-Tools integration and the multi-linguistic facets which have been resolved through some intelligent UX design. This is also part of the optional features (meaning a user can elect to view a record in the view of his choice, its not an "additional feature at an extra cost" :)

Lots of additional documentation can be found under our blog section as well.

We're also introducing a documentation index to centralize relevant documentation for all levels of users. It can be found under the Documentation Index.

Announcing Core Magma 2020

Our latest iteration of a complete 4GL system built on relational databases is out. Christmas time has been very productive for our team, and we've given the finishing touches to our latest integrated creations.

New features

• Label & navigation panel UI editing
• Fully functional data navigation (List, Add, Edit, Delete, Delete-Confirmed)
• Fully functional popup behaviors when drilling data components
• auditable data manipulation (DML) logs
• Fully functional Table Relation UI manager, extends your UI through sound relational theory.
• Adjustable child behaviors through Relation management between objects in the schematic view.
• Options for extending the List views to other types of views (categories, cards, calendars)
• OWASP compliant user authentication and password recovery
• View permissions for the different User Access Levels (ACLs at the View levels*)
• Sorting on any column in List views
• Pagination in List views
• Live editing of List view UI-layers
• Pseudo-live** editing of Add/Edit/Delete view UI-layers
• Added the concept of "gender" to the UI object model when defining display names, this allows for more free-form UI rendering of elements, titles and buttons
• Message Queue service API and UI module
• Bot service API and UI modules
• cascade delete at the engine level using the UI-configured preferences (Jan 5th addition)
• Edit relationship details from the User Interfaces, accessed using the contextual menu on tab headers. (March addition)
• Model maker mini-engine, for preparing our internal packages of data structure (April addition)

notes:

* although we have not implemented ACLs at the Field levels, each View can have different display settings for its fields, effectively granting the ability to mask fields in specific views. This is one of the elected limitations of the system.

**to avoid potential data-loss, the developer needs to manually refresh or submit the current view when in an Edit view

Currently available View types

• listing
• card listing
• calendar view
• dashboard-component
• add, edit
• delete & confirm-delete (with application-level cascade support)

Upcoming View types

• invoice (we're brainstorming the idea of having an Invoice-specific view type, in order to build quotes, proposals and budgets without fuss)
• catalog category, for drilling purposes
• value matrices (combining multi-dimensional tables to generate prices by colour, size and model for example)

Currently available Field types

• text, textarea, tinymce editor, and a brand new content-tools editor (March 2020)
• data is now cipherable using Libsodium's CryptoBox methodology and application-specific crypto keys
• numeric, currencies, date, datetime, time, timestamp
• image, slideshow
• file, file container
• checkboxes, radios, dropdowns and linked-dropdowns
• (new! April 2020) editable lists directly tied to data tables (grab-bags) rendered in an editable list format (like the Blog Categories under the right column in this page)
• ipv4, ipv6
• color picker, font-awesome icon picker
• password (properly hashed)
• [new] crypto hashes of other fields (by reference on inserts/updates)

Field automation scripts

• session->get_UserID(), session->get_OrgGroupID(), session->get_SessionID()  (these are fixes from last year's disappearance act)
• datetime "ts_creation" is now automatically considered a mandatory field on row creation and inserted with the current_timestamp, so the sql:Now() script is now optional.
• (we normally recommend "ts_Change" as a timestamp field to fit our infrastructural mold)
• session->params["fieldname"], for complex customizations

Currently untested features

• defining and loading database table objects from CSS and JS. (Again, the coding remains, we just haven't re-tested the integrated works themselves, this feature was left on ice because of the immense client-server load it generates and certain browser lack of features.)

Upcoming features (which we consider a requirement for a full release distribution)

• improving the error reporting at the view & field levels (from the backend to the frontend UI)
• a developer option in different views to instantaneously display hidden fields
• a little QA session on UI-development ACLs (to make sure regular users can't modify anything)
• QA the dashboard components presented in welcome screens
• revise and re-align the documentation
• build a tutorial overlay (js, canvas and so on) for beginners to the application engine
• polish and QA the multi-linguistic messaging across the board (some messages in the latest js prototype code was inserted in english-only)
• see about moving a maximum of javascript coding into external modules, although this task is impeded by the latest recursive nature introduced with the views. (Object related code usually bears the name of the object itself, reducing javascript method naming conflicts)
• complete a marketing website for promoting the SaaS services for Core 2020-Magma
• Integrate customer rollout automation in our current cloud infrastructure through Tlaloc, Bots and the Message Queue (bear eats bear type of thing)
• Start offering customer accounts for web app development.

Currently on hold is the idea of hosting this in (name-your-brand) Cloud. Because we cannot certify their infrastructure against data-theft, we're prone on hosting this service unto our own (already capable) infrastructure for "serious" customers. This might present some limitations for customer acquisition and growth at first, but we feel it's the only way to stay "true" to our security concepts and philosophy. With that said, we do not foresee offering >free< accounts to these systems. Perhaps trials of some sort (refundable trial period most probably to show some proof of engagement).

For the time being, this engine is currently deployed internally for our own customers and their different, customized and dedicated, Extranets.

Why Core Magma 2020?

For starters, we feel that "Core" is an abused word on the Internet. Originally (20 years ago?) the name was quite suitable to our concept of one, core, object model to build upon a multitude of web offerings. Today, online search results only serve the purpose of creating FUD for a potential brand centered on one word such as "Core".

Magma is related to a dream of its lead architect. (a literal one) Always being fascinated by speleology and geology, said lead architect had the occasion to get closer to many volcanoes. They present a form of constance in geological times, yet are always moving, growing or reducing their presentation.

So, we saw fit to apply this name to this system, since that's what it does exactly. It presents, on the surface, managed data that can always be shifting in its constituents, location and presentation, yet around one single core still. Without having to resort to programming directly.

2020, well, the first stable version of what we consider the Magma Version was completed on the abouts of Jan 1st 2020.

the Roadmap ahead

Well, its back to business for the development team, other projects to maintain and setup, so we'll be pushing this new engine strongly in the coming months into new projects, to speedup prototyping time (immensely!) and start organising some major data security departments. All the while making the final adjustments to the language aspects of the interfaces, and probably some of the functionality based on user feedback.

Lots of documentation management ahead for us, so we'll definitely reuse this engine to set those up, internally and publicly. (Like this blog in fact).

And we are currently back-porting the FileManager module using a brand new dual panel interface.

Finally, the hooks are in place for the Automation to come in with big improvements at the design level. We plan to integrate another layer of backend systems including storage-clusters, backend data processing, data-streaming and web services.