A generic website builder, in my mind, is a tool that facilitates building a website using a specific, unified set of tools. In my current experience, Drupal really comes close when a certain set of modules are used to extend its core. What does this mean? Rather than attempt to answer this question with specific Drupal details, I will attempt to lay down the foundation that is decoupled from any offering.
Practically every HTTP application out there is composed of two distinct layers. The content and its presentation. Websites, being HTTP applications share this separation, and the presentation is often manifested as a theme. However, a theme, as a concept, is much more than a presentation layer in its own right. Often it itself is a full blown application. Therefore the first, technical steps in to resolve for a generic website builder starts with a tool that is capable of understanding these two, often overlapping, concerns. This tool needs to give focus to the primary goal of any request, and then provide a window of opportunity to the secondary application to react symbiotically to that original goal.
The Request Manager
The Request Manager is the first tool in-line to facilitate this symbiotic relationship. However, as a stand-alone tool, it is incapable of addressing its domain by itself. Before any request can be managed, a context is generated. A context is nothing more than a mini-environment generated from the current, raw request. This is achieved through the Context Manager. A context manager is a mapping of a specific request to an environment through a configuration. Within such an environment, specific objects are guaranteed to exist by a specification. The Request Manager makes use of two additional tools: the Access Manager, and Selection Manager. The Access Manager is responsible for managing predicates that determine authorization, while the Selection Manager manages predicates for filtering the resultant, displayed content. Both the Access Manager and the Selection Manager configured through the Logic Manager.
The Logic Manager
This tool needs to be so generic, that it displaces, completely, the need to write custom code, allowing a user interface to generate desired results. As the system continually exposes new APIs through extensions, these APIs will invoke customized code that will further extend their functions. The distinction between raw code within these extensions and logic patterns setup and saved to the database by site builders through the user interface should not exist.
The Context Manager
A tool, based on the Logic Manager for mapping raw request data to specific objects that are recognized in a uniform manner by the system. While this concept sounds simple in theory, it is a combination of 2 distinct concepts:
- Argument Manager
- Relationship Manager
The Argument Manager, as its name implies, is responsible for mapping a raw value (often a unique identifier) to an object, this object is then introduced into the environment by a unique name within the current environment. The Relationship Manager is used to expand the current, existing environment with additional objects by extracting them from the already loaded objects and making them available through additional, unique names. Both of these managers delegate to the Logic Manager for processing internally, as it is the central hub of performing actions.
Once the Request Manager process a request, both the main content of the application and the secondary theme content can make use of the information it provides. By normalizing all display of output to be that of a distinct, nested, mini-application, we can make the assumption that when they are displayed in parallel they will have access to the same contextual data. To manage both, however, we need another layer: The Display Manager.
The Display Manager
This is another, very generic tool. As its name suggests, it manages entities that are referred to as a “display”. A display is a named configuration for a layout. A layout is a data-set that describes, abstractly, the visual regions of a screen. To bind content to an area of a screen, a display must be configured with a layout and then selected by the Request Manager for a request. This opens up the interface to place the aforementioned mini-application onto the layout. Each mini-application can in turn make use of any available display recursively until a content atom is finally reached and displayed.
Acts and behaves much like the Request Manager, but is only responsible for inter-application requests. It is the main mechanism of recursion. A mini-application does not respond to HTTP requests, instead it accepts arguments in the form of parameters. These are the only technical differences between a Request Manager and the Mini-Application. This structures allows for concern isolation and provides for the ability to have arbitrary contexts from which to draw from each of the pieces of content at any arbitrary level.