Introduction to realMethods' Technology Stack Packaging
realMethods improves on the concept of a technology stack with we call a Technology Stack Package (Package). A Package not only includes all the concepts of a bundled technology stack, it also includes the template-driven abstractions, features, components, and services of a specific kind of application. Being template-driven is crucial to a package since it is the active tier between a technology stack and an entity model. Importantly, a package can accommodate an endless combination of technologies and application features that are the possible result of even a single entity model.
The Components of a Package
A package is a single compressed ZIP file containing both standard, required, and optional files. The optional files are usually the template version of the files targeted for the resulting application. The following standard files are required.
techstackpackage.xml
This required XML file contains the overall description of the package itself. It is most useful for
the sake of providing documentation as to what the package contains and the general intent of the
The following is taken from the AWS Lambda RDS package:
options.xml
This file contains the options used to make decisions that impact application generation, having implications on how an application is generated and likely how it is built, deployed and executed. It can contain general options specific such as the app name, author, app logo URL. It can also contain options related to such thing as AWS, Heroku, and other target platforms.
Each technology stack package has its set of options contained in multiple options.xml files.
These options are all modifiable, and often contain a default value per the author of the package.
The CLI and API client versions allow you to manage options as a single JSON structure. The browser-based client presents the options as a series of forms and form controls for simple
modification.
mappings.properties
This required file contains the declarations as to where to output a generated file. During code generation,
it provides the flexibility needed to separate where a template file is discovered versus where its generated output should be placed for the sake of coding convention, the build process, application deployment, etc.
The following are sample entries taken from the AWS Lambda RDS package mappings.properties file:
Entry Rules
The format of an entry in the mappings.properties file provides details on how the app generator should process and output the results.
Using the previous sample entries, here are an example of supported formats:
| Procfile= | Indicates to the app generator to process a file named Procfile and output it to the root of the output directory. |
| pom*= | Indicates to the app generator to process any file with a prefix of pom and output it to the root of the output directory. |
| *xml=.src.main.resources | Indicates to the app generator to process any file with a suffix of xml and output a sub-directory /src/main/resources under the root output directory. |
| *__classes__.java=.src.main.java.$packageName.bo | Indicates to the app generator to process any file with a suffix of xml and output a sub-directory /src/main/resources under the root output directory. The $packageName is directive to use the package name option value, with . notation interpreted as a sub-directory. For example, a package named com.company would result in output of com/company/. |
| exclusions=bootstrap-*.js,bootstrap-*.css | The word exclusions is reserved to indicate which files to exclude in the template processing. If listed as a file to handle, the file will be moved according to the rules above, but will be ignored as a template file. |
A template file is extremely generic, and can represent anything but has real purpose towards the overall intent of the package and the application it results in.
As of v1.1, realMethods ingests package template files and processes them using the Apache Velocity Template Engine.
A Velocity template file uses very easy familiar syntax. During generation time, realMethods makes available a standardized internal
version of your entire entity model along with a few helper classes, giving you complete programmatic flexibility and control
over what gets generated.
Key Generation Objects
Let us use a few excerpts from a template file within the AWS Lambda RDS package
Here is the breakdown of the example:
#header()Calls a realMethods provided Velocity macro to output a standard file header (license/usage info, etc..) |
#set( $className = $classObject.getName() )The application generator makes available to the Velocity content the current |
package ${aib.getRootPackageName(true)}.#getDelegatePackageName();The application generator makes available to the Velocity content an object name aib. This object gives access to |
#foreach( |
Overview
As of realMethods version 1.1, the following packages are available to generate an application or download to customize.
Angular 7 -Material Design - MongoDB - Mongoose
Django - Python - Supported database options
Google Functions - Hibernate - Spark MicroWeb
Spark Microweb - jQuery - Hibernate
AWS Lambda - MongoDB - Hibernate - Spark Microweb
ASP.NET 2.0 - nHibernate - jQuery - cshtml
Spring Boot, Hibernate, MongoDB
Apollo GraphQL, SQLite, Sequalize
