Technical MODX: MODX

As the title implies, we focus here on MODX. On a personal note, simply writing this single article is the most difficult thing I have ever done in my short 35 years. When we define MODX here, are we designating the framework, the $modx object, the development environment? All, some or one? Let’s get that right out of the way. The environment is actually just the manager which is a utility that interfaces with the framework. Our second candidate, the $modx object, primarily glues the framework together, and serves as the developer’s interface for the engine. As such, the decision was made to discuss the framework as a single entity.

Clarifying the entire framework to a single describable process is a bold proposition. Without the subsequent articles, much may seem like pushing a square peg through a round hole. However, future episodes in this series expand upon the concepts contained within, necessitating this colossal text as the first installment. For those that were a part of the web before Content Management Systems, much of the contents here will simply be a reminder. Those who were not part of the baby-web should gain a richer appreciation for the process of Content Management. We begin this process by going back to the beginning.

Introducing HTTP

We used to have to type it in whenever we wanted to visit a site. Advertisements used to include “http://” when they pushed their web address. It is still printed on a significant number of business cards. HyperText Transfer Protocol is a simple communication standard that allows a client to Request a resource from any enabled server (HTTP Host) and receive a Response for that Request. What distinguished HTTP from other protocols of the time was the nature of the client/server relationship.

In HTTP, contracts are all originated by the client via an HTTP Request. The Request is provided to the Host as an address with any configuration options. The Host then builds the HTTP Response and returns the type of resource, content of the resource, and status of the contract. The client awaits the Response patiently until it is transmitted or the client cancels the Request. The agreement ends upon delivery of the Response, allowing the client to begin a new contract (via Request). While this protocol dramatically improved the distribution of information, the advent of server-side scripting augmented nearly every aspect of software information systems.

Conceptualizing Server-Side Scripts

HTTP Servers were originally dumb servers that provided static file content as the response for virtually every request. The problem with these dumb servers was primarily that the requestors were smarter than they were. The client was able to interpret the response programmatically resulting in HTML files (and its companions) to be viewed in an entirely different way than they were written. Server-Side Scripting was developed as a way to match the servers’ capabilities to the client.

Server-Side Scripts changed the playing field when it came to content and data. Without a technology like PHP, all the client would ever get back was file content. With PHP installed on a server, that server could now programatically react to HTTP Requests in a manner similar to how a client could interpret and present HTTP Responses. This allows the script to utilize multiple storage mediums, additional operations, abstract request routing and even the ability to generate the HTTP Response dynamically. These technologies primed the web environment for advanced scripts that returned dynamically stored and generated content, known as Content Management Systems

Deriving the Content Management System

When Content Management Systems entered the playing field, website designers were now able to utilize any storage mechanism they could build (or find) a script for. Routers were now able to virtually represent any number and combination of logical models and physical storage constructs. In order for these advents to be useful, there needed to be a methodology to provide these responses.

The CMS provides this by acting as a delegate for handling the HTTP Request so that it can return an HTTP Response. This single observation describes the MODX object in the most concise manner. If you take away all of the other classes, objects and interfaces that compose the MODX framework, the MODX object will still work because it will always generate an HTTP Response. The rest is sugar and convenience, but do not assume this reduces the value of MODX or any of its components.

Center Stage: MODX

On the surface, MODX provides the same function as any other CMS. It is a server-side script that acts as a delegate for an HTTP Server and returns an HTTP Response any time that an HTTP Request results in the execution of the MODX script. What differentiates MODX from its kin is not its function, but how its abstractions correspond to the web protocol.

The original, and initial descendant, CMSes were developed around the concept of standardizing a presentation model, for the purposes of reusing content elements and functions. This has created rifts in terminology, semantics, specifications and implementations. MODX takes a different stance from its rivals. Rather than adhering to a particular presentation paradigm, it abstracts the Request->Response transaction into stages so that developers are able to impose their own presentation standards (or not). The goal is the same: to deliver information and content to its consumers and viewers. This approach is notably more elegant and has myriad applications, particularly when the integral parts of an HTTP contract are correlated to the MODX Objects.

The Host

All HTTP Requests must have a source for the desired information. Often, this is a domain which may or may not have any number of sub-domains. While it is always true that these requests will resolve to a single host, a single HTTP Host may have multiple HTTP Servers. MODX Contexts were developed for this purpose, but have much greater utility.

The Context serves to meet the need of multiple servers, but does so with a particularly interesting caveat. It does not enforce that the provider of the request be a domain, or even sub-domain. In MODX, a Context is simply a segment of the repository that is segregated in logic from the others. This often results in another domain, but may be a sub-domain, sub-path, or even none of these. This simple abstraction has profound effects upon site(s) architecture, development methodologies and, even, workflow.

Response Location

Many Content Management Systems were invented specifically to offer web content. They nearly always assume that the content of the response will be a webpage (HTML) and some even enforce that ideal. In contrast, MODX makes the same general assumption but the MODX environment does not control the content and relies heavily upon the MODX Resource.

If the HTTP Response is indeed a MODX Resource, it reads the properties to configure the HTTP Response and serve the data. By default, the Resource will result in direct transclusion to the Response, but MODX innately provides several facilities to override this. Just so things don’t get too complicated, we have also been given the ability to handle Resources by its encoding. In short, the Resource may be encoded in any structure that the Response can return. Since the HTTP Response is completely agnostic, this may even be a data encoding that has not yet been developed.

Response Encoding

MODX does not know what type of information it will be returning until it actually resolves to the Resource containing the information. MODX handles this via the Content Type. The Content Type may be anything that can be attributed a MIME Type, including binary resources. The nature of this late-binding allows for some impressive capabilities.

This allows a developer to store anything, including binary data such as images and executables into the Resource. It further allows dynamic content returns and, even, real-time manipulation using nearly any other MODX Object in the platform. Not only does it allow us to tailor our responses according to the Resource content, it additionally allows us to easily transform the content into another encoding prior to actually sending the Response, whether implicitly or explicitly. The brilliance of this abstraction is that it is segregated from user-defined presentation models: MODX Templates.

Response Content

The type of content that makes up a response in other systems is often directly tied to the data type of the content, or vice versa. MODX Templates allow us to simultaneously comply with the agnostic nature of HTTP standards and model our personal compositional elements. We may choose that a blog post display and function completely differently from a product page. Amazingly, the presentation model need not ever actually display the content that our Resource actually contains, but may utilize it in any number of other ways.

Response Control

Once a CMS has control of the Request/Response cycle, a lot of benefits reveal themselves. A significant perk is that the CMS may now separate the Response building process into parts, notifying the environment of each step in the process. When modelling the presentation process, the core body of events will be focused on presentation elements and their resolution or integration. This is the primary source of inconsistencies and irregularities across content frameworks, and information distribution, as a whole. MODX events seem just as inconsistent, but this is only because they do not reflect presentation events.

Many default MODX Events directly correspond to stages of building the Response. Most important, these events may easily be handled according to the context (not necessarily MODX Context) in which they are fired. Further, there is no difference between an package’s events and a core event, save that the core does not provide them. Unlike other platforms, there are no (or few) package related events which means that any package is a part of any stage in the process that its developers desire. The ingenuity of this approach is that it still allows for presentation modeling, without constraining the model.

A package, though desirable, is not required for custom events. Any other MODX Object may fire an event by calling a simple MODX Snippet. These events may be as singular or reusable as the site builder requires. The ability to mimic presentation events allows MODX the unique ability to utilize the event structure of any other CMS, importing and translating plugins, themes, and other CMS resources with little effort. Further, it allows MODX to serve as a building and exporting utility for any of of its siblings with even less work. Of course, none of this process matters if our users are not actually getting the information that they want.

Request Route

When we view MODX as a complex router, it makes some of the most rebellious of us wonder “who made MODX king?” Why should it tell us how our site structure should resolve to our resource structure. In truth, it is not and we can take away that power at any time. Other sources indicate that Custom Routing may occur whenever a page is not found. The route, though, is completely removed from both the information it provides and the method by which it is found.

Consider, as an example, a Resource that invokes server-side code as a part of its generation. This is an additional opportunity to reroute information. This new information may be returned directly, transcluded, combined or even redirected. The source of this information need not even be contained within the currently responding MODX installation. Whether a holistic URL scheme, a classified segmentation, or a remotely managed URL API, the only obstacle impeding the client from receiving your desired response is the ability to conceptualize such paradigms.

Maximize on MODX

To summarize everything we have just discussed: MODX is a delegate for the routing of HTTP Requests, which may consistent of other custom routing procedures, to HTTP Resources, which may or may not be classified by distinct presentation models, from logical HTTP Servers to generate HTTP Responses that must either be persistently or dynamically encoded to a handled MIME-Type. (Yes, I just flunked english…) The question now becomes: “What is new about this?”

The quickest and most correct answer to the above question is: there is nothing new here. All of this HTTP stuff has been known to core PHP developers since the dawn of HTTP and PHP. The MODX Team simply chose to abstract and extend the most elementary web technology over a constrained distribution model. The nature of these connections completely alters the relational perspective.

Without this overview, we can only relate to MODX’s kin by either using their exclusive terminology, or by the slightly more objective technologies and standards that they adopt. With this realization, we can address any differences directly by bringing them to the standard of the world wide web: HTTP. Further, these correlations allow a plethora of possibilities when one studies the technical details of these other web advancements:

REST is a URL-enforced schema that objectifies HTTP Resources and connects them to the methods that manipulate them via HTTP verbs.
AJAX is a HTML technique that allows preliminary HTTP Responses to make subsequent HTTP Requests on behalf of the HTTP Client and utilize their HTTP Responses.
cURL is a server-side interoperability medium that allows a Server (of any type) to become an HTTP Client of another HTTP Server.
CORS is a server-configured client-side inclusion and interoperability mechanism that allows Servers to define which HTTP Resources may be shared to HTTP Responses that do not originate from itself.

There are two things in common about the above list: the aggressive employment of HTTP; and their utility is contingent on their objective design. MODX is different because, as a development tool, its users must be able to apply that same objectivism to extrapolate the possible applications for each component. This becomes increasingly difficult as several MODX Objects serve multiple purposes. The first step to future success here is simply to begin thinking of every MODX Object as a facilitator of some aspect of or step in the HTTP transaction.

Think Forward

While other CMSes are adopting and advancing new and future presentation standards, they are continually struggling to fill the gaps that their presentation-centric approaches have left. In contrast, MODX may adopt and implement any such standard (as a framework, tool, or blend of MODX Objects), but seems continually behind in its own integration of these practices. The reality is significantly more complex in that our beloved tool already has what other CMSes want, but lacks what developers in those other platforms feel they need.

Attempting to fulfill these needs requires comprehension of the roles that the HTTP core concepts play in the use of MODX’s abstractions. When we correlate the framework’s objects and stages to the protocol that defines over 95% of web interaction, we gain an objective perspective from which to efficiently adopt, integrate, apply and expand upon not only the current standards, but emerging technologies. Our next step will be to explore the MODX Object that most directly corresponds to the purpose of all HTTP interactions: the MODX Resource.