The concept of parser php-> php

After several projects, with bloated structures and an elusive inhibiting structure of the inclusive, I tried to do something more convenient and optimal.
It all started with the fact that I tried to get rid of inkludov. Yes Yes :)
The paranoid optimization of each line and tests led me to the conclusion that to achieve maximum optimization,
it is necessary that each page uses only the necessary structural blocks. And all these structural blocks should be part of the page.

Just at that time I was actively studying the implementation of OOP in php, and
I decided in my parser to call the structural blocks - containers, which are class methods.
Now the whole project was presented to me in clearly structured blocks, each of which could be used anywhere on the site. For a better perception of the structure, all blocks use incorrect tags, for which I use purple in Zend Studio.

I will give an example of the structure for the main page of the site:


')
Why is it convenient for me:

1. Flexible development management

Often you have to deal with the fact that it is necessary to urgently make some changes to the site, but at the same time editing
responsible for connecting to a database or other critical parts of the site, you make a mistake and the site meets new visitors with a dull design (at best) or a complete lack of content.
I have seen so far only 2 solutions to this problem:
Editing a copy of the file on one of the hidden pages of the site or editing the site on a local server and then downloading the already working model.
Well, the most crucial, this is editing at night, when most of the users are no longer up to your site.

In my parser, I specify which pages to recreate with a regular expression.
Therefore, we can conduct tests on one page of the site, or on the whole segment, and then instantly update all the others :)

2. Control over the project code

Php files are most often stored right in the root of the site, and subdirectories, and absolutely do not maintain order.
Some webmasters do not even know what code they have and begin to write again the functions that are buried in the depths of the site.

With the help of this parser you can store all the code of your project in a single file (for example project.xml).
However, this is not a requirement. For convenience, you can create any number of files and put them in a directory as you please.

3. Flexible syntax

When studying new frameworks and template engines, you often fall into a stupor from illogical, as it seems to you, function names.

In the parser, you can set whatever names you like and change their actions. Add or delete unnecessary functions.

4. Optimization of php, css, (x) html code

There are a lot of scripts for compressing css and (x) html code. But Zend Optimizer is far from being on every hosting, and
not everyone can afford such hosting. Yes, and do not forget about include? :)

In the parser you can optimize the php, css, (x) html, js code as you like. The function you specified is a la include
will insert the contents of the file directly into the page.

5. Create static html sites

To create static sites, you no longer need to write self-made parsers, mine copes with this very well :)

Where to start?

First we need to have 3 files:

1 - the compiler itself (ajax also comes to it for convenient work)
2 - the main project file (for example project.xml)
3 - valid page file (just a list of pages that we need to recompile)

Now, we need to decide which markup we want to use.

General rules

If your project actively uses OOP, in order to avoid conflict situations, we will specify the classes to be used in the markup.
By default, global project rules are defined in the construct.
for example

! class area
! class unicate
! class moiclass

We can come up with and use our markup, for example

#define moiclass

In any case, if the parser does not find global rules, all constructions that fall under the regular expression will be analyzed.
for valid classes.

Why else global rules?
Example: You have decided to add just one line to all pages of the / catalog / directory <? error_reporting (0); ?>
With the! Method. AddBefore.regexp (^ / catalog /). String {{{<? error_reporting (0); ?>}}} (cite as an example)
We will add this line to all lines starting with / catalog /.

The layout of the main structures

UPD: In accordance with the basics of Aspect-oriented programming, fixed the basic concepts.

JointPoint (<class :: method> by default) is a specific point in the program execution: execution of a method, change of a class attribute,
method call, throwing an exception, etc.

<class.method> </ class.method> (Aspect) An analogue of a class can contain an unlimited number of JoinPoint (<class :: method>) or just php / html / css strings.

#include file is a simple replacement of the string with the file contents.

UPD: Thanks for the comments, not knowing about the existence of AOP used its principles.