Controllers

Team. This project has manifold purpose. In other words, it is worthwhile for many different reasons. First, it is an exercise in "polyglot" programming, in that it provides fourteen functionally-equivalent software products. The author crafts each in a different high-level computer programming language. 

And, this also is a valuable exercise since it creates a general-purpose controller. This architectural software structure is very common and  found explicitly or implicitly in every interactive system. In terms of software engineering theory, it is an archetypal module for all systems that accept input and produce output. It is the locus of the system's logical processing.

For systems that are layered, usually with presentation, middle-ware, and data-entity tiers, the controller is a way of viewing the role of the middle-ware business logic.

This a fundamental structure in software engineering and system development. It is much like a compiler and interpreter. One does not write a "fresh" instance of one of these language tools each time he needs one. Unfortunately, in the "medieval" days of computing, 1970s - 1980s, a vision for the "pre-rolled" component that controlled the logic the logic of any system was not envisioned. So, the common function of the control unit was rewritten each time it was needed. This counters the principles of software reuse and write once run many (WORM).

The field of software architecture was conceived in the Spring of 1989 based upon the author's best recollection. The first conference on the topic was in the Fall of 1989 as modern records show. It was during this Spring that insight and innovation inspired the birth of the basic architectural assemblies of layered and model-view-controller systems. This was one catalyst driving the modern computing renaissance of the mid-1990s with its world-wide web and markup languages for "typesetting". 

With the advance of the discipline of software engineering during the 1990s and early millennium, the community was given various "prefabricated" controller products such as Struts, Spring, and Laravel. Yet, none of these are truly "general-purpose", nor can they as easily integrate functionality as the product under development in these fourteen languages. Plus, Struts and Spring are only compatible with JAVA and Laravel only supports PHP (the personal hypertext processor).

And, one of the most wonderful aspects of the current system implementation of this general-purpose controller is that it is very simple, a small coding effort, and one which you can build yourself and customize as needed.

Foreshadowing future software engineering practices, "general-purpose" controllers supporting dynamic invocation might soon be a standard language component much like compilers and interpreters. 

Oracle and Microsoft each have modern MVC products. The author is familiar with Oracle's Ozark product which provides a "flexible" controller product for use with RESTful web-services. Yet, outside the realm of web transactions, Ozark does not support the dynamic invocation of "user-defined" methods in other instances. At least, this is how the author understands this product. And, Ozark systems cannot be "wired-up" as easily as this "simple" products architectural control language (ACL) file. Ozark systems must have their logical flow described within the JEE controller's source file. In some sense, those logical concerns are tangled up with other source code concerns. It might be the case that this use of an ACL file provides a better partitioning of system concerns.

In short, this structure for architectural controllers might become a "de facto" standard. Primarily, because it is "simple" in design and "straightforward" in its use, much like HTML.