QuadBraces — based parser MODx

Good health hebraically!

When I looked in the source MODx Evolution, I almost had a stroke. Refactor, refactor and refactor as we would say. According to this, I had barely a couple of weeks of refactoring, and then I threw this business, for the time frankly was not. But the conversation will go not about it.

The MODx templating system in my opinion is one of the best. Especially good job developers in MODx Revolution. Everything is logical, extensible, flexible, and downright pastoral. You can tell, the syntax of the templating MODx is almost a separate markup language. It is now the admiration was the reason I began to use this technique in other projects. And in order not to hammer a microscope nails, that is, not to put landing pages to MODx, but to be able to use this standardization, I wrote a separate class of the templating engine. And even gave the name — QuadBraces.

However, the first thing I want to warn is that the usual MODx-EPAM chunks, templates, snippets, and extensions to the parser is stored in the database and in files. The path to the data file template is determined by determining the constants QBPARSER_TPL_PATH.

the

Features


the
    the
  • Recursive processing of text data;
  • the
  • Used element types: chunks, constants, setup, placeholders, debug, snippets, language constructs, autotitrator;
  • the
  • Possibility to determine the so-called template-packs (in the templates folder of the parser) that allows you to develop, install and use a ready-made template packs (as in Unnamed-I-Usually-Engine);
  • the
  • the Possibility of structuring template content. Point the alias to the chunk / template / code snippet means in fact a directory-separator;
  • the
  • Errors throw exceptions, which makes it easier to debug your code;
  • the
  • setting the array of placeholders and "settings" implies the addition of existing data;
  • the
  • Ready algorithms accessors;
  • the
  • In contrast to MODx depth of nesting of snippets is limited only by the maximum processing level of the parser.


In essence, this class is a recursive handler text on regexps. The data for the placeholders and "settings" are defined by the end developer. Similarly, with snippets — it's already on the conscience of those who will use this class. I mean write =)

The source code is available on GitHub here — github.com/XanderBass/quadbraces

An example of using the parser:

the
<?php
require 'qbparser.php';

$parser = new QuadBracesParser();
$parser->templatePack = 'default'; // Set template-Pak
$parser->template = 'index'; // Set the template
$parser->data = array(
'foo' => 'bar',
'pagetitle' => 'Test page',
'content' => 'Hello world!'
);
$parser->settings = array(
'my_setting' => 'My configuration adnaka'
);
echo $parser;
?>


Pay attention that the parser supports the language constructs. Dictionaries must be in the language folder (default QBPARSER_TPL_PATH.'lang'.DIRECTORY_SEPARATOR), where each subfolder corresponds to its name the signature of the language (e.g. EN or de). Each dictionary file must have the extension. lng and contain a set of strings separated by "|". The first element of this string is the key, the second a caption element, the third element of hint.

When you search for chunks, templates, and snippets (and extensions) searches for the so-called localized elements. This feature allows you to create a separate implementation chunks for specific languages.

By the way, to the question of variables. Actually add a variable equal to the addition of the placeholder.
the
<?php
$parser->data = array(
'items' => array(
array('id' = > 1,'title' => 'Item 1'),
array('id' = > 3,'title' => 'Item 3'),
array('id' = > 2,'title' => 'Item 2')
)
);
?>

This code will not overwrite the entire data array of the parser. This code will only overwrite the "items" of this array, if one exists (if not create).
the

computer Support


the is eq — equality (compare value, then, else)
is not, neq — inequality (comparison value, then, else)
lt — less than (comparison value, then, else)
lte is less than, or equal to (comparison value, then, else)
gt — more than (comparison value, then, else)
gte is greater than or equal to (comparison value, then, else)
even is a sign of parity (compare the value, then, else)
odd is a symptom of odd (compare value, then, else)
for — an integer iterator (iterations, start, splitter)
foreach — the index of the iterator (the list of indexes separated by commas, splitter)

For the for available internal placeholder [+an iterator+] containing
the number of the current iteration.
— To expand the inner foreach is available placeholders:
[+an iterator.index+] is the position number of the current iteration,
[+an iterator+] — the current index

the

Examples of opportunities



the
{{path.to.my-chunk}}
displays the processed contents of the chunk in file /path/to/my-chunk.html in the folder of the parser. As I said, allows you to structure data templates, not dumping all in one pile.

the
{{my-chunk &foo=`bar`}}
displays the processed contents of my chunk-chunk, replacing it inside the placeholder [+foo+] on the string "bar". This feature eliminates the need for bulky snippets-iterators. You need to withdraw in landing a dozen projects? There is nothing easier! Create chunk output for the project, and on the page a few times stupidly call it, substituting the desired local parameters — PROFIT!

the
[*cool-data &foo=`bar`*]
same as above, only with a placeholder cool data.

the
[*cool-data:empty=`bar`*]
if a placeholder is cool-data is empty, the string "bar"

the
{*MY_CONSTANT*}
will output the contents of the constant MY_CONSTANT, if any, is determined. Works with any constants. Be careful with "magic" constants. Sometimes curious things happen.

the
[!my.cool.snippet:empty=`busconfig` &argument=`foobar`!]
will Execute the snippet my/cool/snippet.php from a folder template, passing as arguments the array containing the element with an index argument and a value of "foobar". If the result of the snippet will be empty, just the string "posconfig".

the
{{my_chunk:for=`6`:splitter=`< br / >`}}
will display a chunk my_chunk 6 times, dividing the output by using the tag < br / > (remove the spaces in the tag)

the
[%error-message.hint%]
displays a HINT of the language element error-string if the language is loaded

In General, you can fantasize endlessly about the application of this parser. The basic examples in the README on GitHub. According to this experiment. In the comments, ask questions, and write error, if any. I checked — all works.

the UPD 1:
— Now available on GitHub here — github.com/XanderBass/quadbraces
— By popular request (there was irony) added iterators
Code formatted a little better
— Added language constructs and the search for localized versions of file elements

the UPD 2:
— Added autotitrator of data array elements that are arrays
Article based on information from habrahabr.ru

Комментарии

Популярные сообщения из этого блога

Address FIAS in the PostgreSQL environment. Part 4. EPILOGUE

PostgreSQL: Analytics for DBA

Audit Active Directory tools with Powershell releases. Part 1