QuadBraces - based on the MODx parser

Good health habrazhiteli!

When I looked into the sources of MODx Evolution, I almost had a stroke. To refactor, refactor and refactor, as Ilyich would probably say. According to this, I was barely enough for a couple of weeks of refactoring, after which I abandoned this case, because there was no time for that. But the conversation goes about it.

The MODx templating system in my opinion is one of the best. The developers at MODx Revolution tried their best. Everything is logical, expandable, flexible and straightforwardly pastoral. You could say MODx templating syntax is almost a separate markup language. This admiration was the reason why I began to use this technique in other projects. And in order not to nail down the microscope with a microscope, that is, not to put MODx for Landings, but to be able to use this template, I wrote a separate template template class. And even gave the name - QuadBraces.

However, the first thing I want to warn you about is that the usual MODx-eram chunks, templates, snippets and extensions in the parser are not stored in the database, but in files. The path to the file with the template data is determined by defining the QBPARSER_TPL_PATH constant.
')

Opportunities

• Recursive processing of text data;
• The types of elements used: chunks, constants, installations, placeholders, debugging, snippets, language constructs, auto readers;
• The ability to determine the so-called. template packs (in the parser templates folder), which allows you to develop, install and use ready-made template packages (as in Unnamed-by-me-usually-engine);
• The ability to structure template content. A dot in a chunk / template / snippet alias means actually a directory separator;
• Errors generate exceptions, making it easier to debug the code;
• Setting an array of placeholders and “settings” implies the addition of existing data;
• Ready accessory algorithms;
• In contrast to MODx, the nesting depth of snippets is limited only by the maximum parser processing level.

In essence, this class is a recursive text processor on regulars. Data for placeholders and “settings” are determined by the final developer. Similarly, with snippets - this is all on the conscience of the one who will use this class. In the sense of yourself write =)

Class source is available on GitHub here - github.com/XanderBass/quadbraces

Example of using a parser:

<?php require 'qbparser.php'; $parser = new QuadBracesParser(); $parser->templatePack = 'default'; //  - $parser->template = 'index'; //    $parser->data = array( 'foo' => 'bar', 'pagetitle' => ' ', 'content' => 'Hello world!' ); $parser->settings = array( 'my_setting' => '  ' ); echo $parser; ?> 

I pay attention that the parser supports language constructions. Dictionaries must be contained in the language folder (by default, QBPARSER_TPL_PATH.'lang'.DIRECTORY_SEPARATOR), where each subfolder corresponds to its own language signature (for example, en or ru). Each dictionary file must have the lng extension and contain a set of strings separated by the character "|". The first element of such a line is the key, the second is the caption element, the third is the hint element.

When searching for chunks, templates and snippets (and extensions), a so-called search is performed. localized items. This feature allows you to create separate chunk implementations for specific languages.

By the way, to the question of variables. In fact, adding a variable is equal to adding a placeholder.

 <?php $parser->data = array( 'items' => array( array('id' => 1,'title' => ' 1'), array('id' => 3,'title' => ' 3'), array('id' => 2,'title' => ' 2') ) ); ?> 

This code will not overwrite the entire data array of the parser. This code will overwrite only the “items” element of this array, if it exists (if not, it will create).

Supported extensions

is, eq - equality (compared value, then, else)
isnot, neq - inequality (compared value, then, else)
lt - less than (compared value, then, else)
lte - less than, or equal to (compared value, then, else)
gt - more than (compared value, then, else)
gte - greater than or equal to (compared value, then, else)
even - a sign of parity (compared value, then, else)
odd - a sign of oddness (compared value, then, else)
for - integer iterator (number of iterations, start, splitter)
foreach - index iterator (comma-separated list of indexes, splitter)

- For extension for available, an internal placeholder [+ iterator +] is available , containing
current iteration number
- Internal placeholders are available for foreach expansion:
[+ iterator.index +] - the position number of the current iteration
[+ iterator +] - current index

Examples of opportunities

 {{path.to.my-chunk}} 

will output the processed contents of the chunk located in the /path/to/my-chunk.html file in the parser folder. As I said before, the ability allows you to structure the template data without dumping everything in one heap.

 {{my-chunk &foo=`bar`}} 

will output the processed contents of the my-chunk chunk, replacing the placeholder [+ foo +] inside it with the string “bar”. This feature allows you to do without cumbersome iterator snippets. Do you need to display dozens of projects in the landing page? Nothing is easier! We create a project output chunk, and on the page we stupidly call it several times, substituting the necessary local parameters - PROFIT!

 [*cool-data &foo=`bar`*] 

the same as above, only with a cool-data placeholder.

 [*cool-data:empty=`bar`*] 

if the cool-data placeholder is empty, the string “bar” will be displayed

 {*MY_CONSTANT*} 

will print the contents of the MY_CONSTANT constant, if one is defined. Works with any constants. Be careful with the "magic" constants. Sometimes curious things happen.

 [!my.cool.snippet:empty=`` &argument=`foobar`!] 

Perform a snippet of my / cool / snippet.php from the template folder, passing as arguments an array containing the element with the index index and the value “foobar”. If the result of the snippet is empty, it displays the string “empty”.

 {{my_chunk:for=`6`:splitter=`< br / >`}} 

will print the my_chunk chunk 6 times, dividing the output with the help of the tag <remove / remove spaces in the tag)

 [%error-message.hint%] 

will output the HINT language element error-string if the language is loaded

In general, you can infinitely dream about the use of this parser. Basic examples are in the README on GitHub. So experiment. In the comments ask questions, and write about errors, if any. I checked - it works.

UPD 1 :
- Now available on GitHub here - github.com/XanderBass/quadbraces
- By numerous requests (there was irony here) iterators were added
- The code is formatted a little better.
- Added language constructs and search for localized versions of file elements

UPD 2 :
- Added autoiterators of data array elements, which are arrays