MetaGenesis MetaLX vs Apache Velocity

These technologies have both common goals and a common approach and at a macro level, remarkably similar terminology. Certainly the syntax is different, but the packages have a lot in common.

Variables, Directives, Comments and Control

Both packages share the two basic concepts of "Variables" and "Directives". MetaLX does not directly provide in-code comments and avoids code control as much as possible.

Comments:

Velocity provides: single-line, multi-line and multi-line doc comments with annotations.

MetalSrv provides: No comments.

Here are my thoughts on the subject.

• If you want in code comments, use the comments native to the environment you are in.
• If you are in HTML use <!-- commnent -->
• Variables and directives are references to server-side data or operations. As such, we believe they should be documented on the server-side.
• MetaLX directives are all "named directives" and are created in the MetaGenie CDE, which allows providing a full description for each directive. There is no reason to double document.
• Since there is little to no "code control" provided by MetaLX, there is little client side logic that needs explaining.

Variables:

Velocity: variables start with $ and it is unclear (to me and the Velocity engine) how they end. (Example $myVar or $my1-Var) Velocity documentation goes into detail on how to use a ${myVar} format because the $myVar format does not always work and may throw an exception..

MetaLX : variables start with "$" and end with ";" (Example $myVar; or $my1-Var;) There is no need for another format, this one works.

Both MetaLX and Velocity allow variables to be set in the front end code.

• Velocity: #set( $myVar = "myValue" )
• MetaLX: <mg-SET:myVar="myValue"/>

Both MetaLX and Velocity allow variables to be set in the server side code.

MetaLX allows variables to be set via the url parameters: https://myDomain.com/myPage.mtl?firstName=Bob&lastName=Brown& (I use this ALL the time.)

MetaLX supports simple and structured variables:

• simple: $myVar;
• Hash/record: $myRecord{}; where individual elements can be accessed: $myRecord{columnName};
• Array: $myArry[]; where individual elements can be accessed: $myArray[3];
• Array of Hashes (aka table): $myArrayHash[]{},
  • where records can be accessed: $myArrayHash[3]{};
  • and individual elements can be accessed: $myArrayHash[3]{columnName};

MetaLX supports page, user/session, application and system variables. They are stored very differently, but accessed in a similar fashion.

• $pageVar; They have the standard $ prefix. They only last for the life of the page.
• $User.user{firstName}; They have a $User. prefix. These last for the user's session.
• $App.counts{userCount}; They have a $App. prefix. These are application wide variables.
• $Sys.serverTemperature; They have a $Sys. prefix. These are system wide variables. Typical vars are Date, Day ot the week.

MetaLX supports NESTED VAR NAMES (Mind blown!): $myArrayHash[$rowNumber;]{$columnName;};.

Here is a snippet of a REPORT that prints out specific columns of a table.

<!-- The variable $number; is automatically generated by the implied list.-->
<!--startList-->
tableName[$number;]{firstName}, tableName[$number;]{lastName}, tableName[$number;]{phone}
<!--endList-->


Null/missing var handling.

• Velocity throws an exception.
• MetaLX default is to remove the var and show nothing. Optionally, MetaLX can be set to show the var name (when in development) for missing data.

Directives

This is where Velocity and MetaLX take different paths.

In MetaLX the directives have a type and a name. Here are a couple of examples that cover almost all of MetaLX.

• <mg-SET:myVar='myVarValue'>
• <mg-QUERY:users?param1=valueOne&param2=valueTwo>
• <mg-REPORT:userList?param1=valueOne&param2=valueTwo>
• <mg-FORM:addUser?param1=valueOne&param2=valueTwo>
• <mg-INCLUDE:codeFragment;/>

The set directive sets a variable, the query directive runs a query (and sets a variable). The other directive are essentially includes, for including more code. Reports, forms and includes all fetch the related code and put it in the page where the directive appeared. These can all have directives in them, a report can have a form in it and vice-versa.

They have some differences:

• Includes are a "dynamic" includes and can target files and code fragments within the files.
• Forms can be passed parameters and the form will be filled appropriately.
• Reports as mentioned can have implied lists.

MetaLX reports are similar to Velocity Velocimacros ( which I will call macros) They simply bring in a chunk of HTML/JavaScript/CSS code. They support implied iterators.

Control (If, Else, For)

MetaLX has resisted providing general control features. Instead it provides "atomic" conditional assignments.

• <mg-SET:someVar="2" if($today;=="Tuesday") default="1";/>

It also provides implied "if" and "for" in reports. Reports present information based on a table register. If the register has no data the "zero report" is presented. If the register has data, that data is presented. If the report is of type list ( they are either text or list)
<!-- Any code before the list goes here.-->
<!--startList-->
<!--This is a single row for the list code. It will be replicated for each row in the list.-->
<!--endList-->
<!-- Any code after the list elements goes here.-->


Single Page Applications

MetaLX directives can be easily wrapped in an MetaGenie JavaScript onClick event call. The directive does not change, and the resulting code is returned back to the element that called it. This makes it very simple to convert multi-page applications to single page applications.

Server side directive for a MPA:
<mg-QUERY:myQueryName?someQueryVar=$usersChoice;;REPORT:myReportName;");/>

Client side directive for a SPA:
<button onclick='MetaGenGet("QUERY:myQueryName?someQueryVar=$usersChoice;;REPORT:myReportName;");'>Request Report</button>

Example:

Summary

The Velocity and MetaLX packages offer very similar functionality on the same technology stack.