Melbis Shop6Calling a module script
The formation of the showcase begins with root scripts , for example - index.php . This root script determines which module script will be called first. Having read the section on using root scripts, you already know the first way to call a module - using the parser $gParser->Parse . Now it's time to talk about the second method, when subsequent modules will call each other using special keys. These keys are located in HTML templates and framed in curly brackets so that the parser can recognize them. These keys can be simple, so-called predefined keys ( system keys , global keys ), or more complex commands to call another module script.
Let's turn to the melbis_base_topic.php module. This module is called from the root script index.php when we open any section of the store. We will postpone the consideration of the module itself for later, but now we need to understand how modules are called by each other.
Let's open the main.htm HTML template for the melbis_base_topic.php module. Among the usual HTML code, you can see instructions for the parser enclosed in curly brackets. For example, there is a simple key UTF-8 . This is a system key and the encoding that you defined for the store in the " Installation " section will be substituted in its place. There are also more complex keys like {MELBIS:PAGE:NAME} , which are formed in modules by the developer, but let's find another key that will call another module, here it is:
{MELBIS:melbis_store_topic([MELBIS:PAGE:ID])}
What does it consist of? First, it is the keyword MELBIS , which is necessary for the parser to understand that this set of characters is the module call command. Next, after a colon, comes the name of the module being called melbis_store_topic , and in brackets are the input parameters of the module. In our example, this is one parameter, and it is dynamic (it is the key in square brackets - [MELBIS:PAGE:ID] ).
So, we have a command to call a module script. What happens next? Then the HTML template parser starts calling the module script and stops waiting for a response from it. Each module script performs its own specific task, based ONLY on the input parameters. The result of the module's work will be a fragment of HTML code, which is then returned back to the parser. The parser, having received this result, substitutes the HTML code in the place where the module call key was.
How does the module script work? In addition to input parameters, it has the ability to use ready-made tools for working with data, using the main parser pointer. For example, the most necessary and simple - it can access the database and get the necessary information from it, and also use the module's HTML templates to compose them in the desired way.
It is very important that the HTML code fragment returned by the module may, in turn, contain a command to call another module. Thus, modules can be infinitely nested (on the other hand, you should be careful with mutual recursion). Another important point is that the call of the nested module script will occur only after the parent module script has finished working.
That's all, actually. After the main parser has finished searching and replacing HTML code fragments, the page will be ready, control will be returned to the root script, which will only have to publish it.
The above-mentioned call options apply only to regular module scripts that form the storefront or other service pages of the site. However, there are also special library modules that we discussed earlier. Such modules, in addition to being able to be attached to regular modules to increase functionality, can also be called separately. For example, in the original store, there is a module melbis_inc_logic.php that contains universal functions for creating and calculating an order. This module can be called directly from the Melbis Shop program itself. Which module to call to place an order is specified in the "Settings Registry" section, and an example of its call is mentioned in the " Orders " lesson.