Hello everyone. I would like to present another bike written in PHP using Document Object Model. How is it different from other three-wheeled representatives of the same species? In fact, there are not so many differences, it combines the best of many. For example:

1. Complete separation of html and php.
2. No additional labels in templates like

3. Ability to embed the content of other template files into the layout, both from php and using a special tag in the layout.
4. Ability to create any html tag on the fly.
5. Ability to save in html file everything that was generated and collected.
6. Checking the existence of the html file of the requested page before generating the template.

To make it immediately clear to everyone how convenient and easy it is to use, I will tell and show how I used it to create one of my projects (I suspect that I will rewrite all my projects for it).

The first thing I usually do is get all the information from the database about the page ( keywords, page description, template name and css and js file addresses). All this I store in the $ head array. Then I get the content from the database and save it to the $ page array. And I start working with the class.

So, first I call the class constructor and pass all the required parameters into it:

$ tpl = new Template; $ tpl -> ext = TPL_EXTENSION; # extension of files in the template directory $ tpl -> htm = CACHE_EXTENSION; # extension for already generated pages $ tpl -> skin_dir = DIR_TEMPLATES; # directory containing all site templates (for example templates) $ tpl -> js_dir = DIR_JS; # directory where you need to look for JS files $ tpl -> css_dir = DIR_CSS; # directory where the CSS is located $ tpl -> img_dir = DIR_IMG; # directory where pictures $ tpl -> skin = $ _SESSION ["skin"]; # the name of the template I want to use $ tpl -> cache = DIR_CACHE; # where to save the finished html $ tpl -> log = FILE_T_LOGS; # where to write logs $ tpl -> tag_start = SYMBOL_START_TAG; # The character that the variables in the template start with $ tpl -> tag_end = SYMBOL_END_TAG; # The character that ends the variables in the template $ tpl -> dir_delimeter = DIRECTORY_SEPARATOR; $ tpl -> space = SYMBOL_SPACE; # character replacing a space.
Fuf, it seems like all the variables have been passed, let's move on.
In order not to force the class to do unnecessary work, first we check if we already have a ready-made Html file of the requested page.
if ($ tpl -> TestPageStatus () === TRUE) (require $ tpl -> cacheFileName;) else ($ tpl -> page ("index"); # pass the name of the template file, by the way, you can pass several of them, separated by commas $ tpl -> assign ("HEAD", $ head); $ tpl -> assign ("CONTENT", $ page); $ tpl -> build (); # give the command to build the template $ tpl -> ShowPage (); # output.)
Here are all the methods you need to use to display the page.

Now let's take a look at a couple of useful methods of this class. Let's say that we have already passed everything we need to the class, but have not yet given it a command to output, because we suddenly remembered that we need to create several Html tags in the template. This is also very easy to do. First, we need to find the block in which we want to add something. You can find it in 2 ways:

$ tpl -> findById ("findMe"); $ tpl -> findByTagName ("div");
The findById method logically assumes that all tag ids in the template are unique. And the findByTagName method will return the first one that matches.
We must pass the result that we got by searching to the $ tpl -> createChild () method in order to be able to create child tags in the found element. The createChild method, by the way, after creating a new element, returns it to us, so that we can use the newly created element elsewhere.

Poking around and experimenting, I found 3 ways to create tags in a template, so I'll show you 3 examples at once. Example 1:

We need to create

inside

$ parent = $ tpl -> findById ("parent"); $ tpl -> createChild ($ parent, "div", "id = child, class = test");
We get:

Example 2:

We need to create

inside

$ parent = $ tpl -> findById ("parent"); $ tpl -> createChild ($ parent, "div", "id = child, class = test", "Some text");
We get:

Example3:
We need to create

in the first span element that comes across

$ parent = $ tpl -> findByTagName ("span"); # (1) $ tpl -> createChild ($ parent, "div", "New Element"); # (2)
(1) Searching for a parent not by id, but by tag will find the first matching one
(2) If we do not need attributes, but only the value of the new element, then they can be omitted.

We get:

And after these manipulations, I already call ShowPage. And here we smoothly come to 2 more interesting points.
Imagine a situation that we have a template, suppose it is a list.tpl template with a list of, say, mobile phones:

If we transmitted information only via 1 phone, then the variables will simply be replaced by their values, and if we transmitted information via several phones at once, then the class will copy this section as many times as the variants of values ​​came to it. And he will do this himself, unlike, for example, the xTemplate class, which had assign and parse for each value
True, there is one not very convenient moment, if after this block there are some others, for example:

Then in such a situation we will have to use a little trick by packing our mobile phone

In this case, all mobile phones will appear one after another, inside , and "Some other block" will remain below.

And, if I haven't forgotten anything, then the last moment is adding the content of other templates to the current template.
I appeal again to your imagination.

Imagine that the layout designer wants the contents of the page.html file to be added to the list.html file block, for this he adds in the right place in the list.html file page and when the class sees this tag it will replace it with the content of the page.html file

The number of such inserts is not limited and their location is absolutely not critical, so you can insert them as you like and in any quantity.

That's probably all, if I remember something, I will inform you additionally. Thank you for reading to the end.

Tags: php, class, template, template engine, parser

After creation info-file, in principle, the topic has already been defined. This means that you can go to the section for managing themes http://mysite.ru/admin/build/themes and include your theme there. Naturally, after turning it on, you will not see any design - the page will acquire the "black on white" style - black text on a white background.

However, I want to note that despite the fact that in our theme there are no files except mytheme.info does not lie, the site will work the same way as before - display all content, add blocks to regions ( http://mysite.ru/admin/build/block) etc. This is due to the fact that the core of Drupal includes required modules, which, even in the absence of any files in your theme (with the exception of the info file), allow you to continue working with Drupal.

In principle, all template creation is reduced to overlapping template files (they have the extension .tpl.php) standard modules of our CMS.

The most important tpl file (tpl is short for template, pattern) is page.tpl.php... He is responsible for building each page of the site. Let's see what the template file consists of:

• html code
• php code
• javascript code(not necessary)

Drupal transfers site data to each template file in the form of standard variables. There are 2 types of variables for each template file:

• variables that are passed only to this file
• variables that are passed to all files

Here is a list of all the variables for page.tpl.php:

Common variables (for all files):

• $ base_path- base path where drupal was installed
• $ css- an array of css files connected to the current template file
• $ directory- path to the folder where the theme is installed
• $ is_front- returns TRUE if you are on the main page
• $ logged_in- returns TRUE if you are logged in
• $ is_admin- returns TRUE if you have access to the admin panel

Page metadata

• $ language- (an object) Current language which is displayed on the site
• $ language-> language- contains its textual representation
• $ language-> dir- contains the direction of the language. It will either be "ltr" (left-to-right) or "rtl" (right-to-left)
• $ head_title- modified version of the page title, for use between tags
• $ head- inserted between tags ... Contains meta tags, keywords, etc.
• $ styles- serves to download all css-files to the current page
• $ scripts- serves to download all javascript "s to current page
• $ body_classes- a set of classes css for tag ... It contains information about the current location of columns on the site, their number, current url "e, etc.

Information about the site

• $ front_page- the address of the main page of the site. Better to use this variable to refer to home page since it includes the domain language and prefix
• $ logo- path to the site logo, if it is included on the site
• $ site_name- site name. It can be empty if you disable it in the features in the info file. Configurable at mysite.ru/admin/settings/site-information
• $ site_slogan- the slogan of the site. It can be empty if you disable it in the features in the info file. Configurable at mysite.ru/admin/settings/site-information
• $ mission- the mission of the site. It can be empty if you disable it in the features in the info file. Configurable at mysite.ru/admin/settings/site-information

Navigation

• $ search_box- contains html code that displays the search string. May be empty if you turn it off in the info file
• $ primary_links
• $ secondary_links- an array containing navigation links for the site, if they are allowed in the info file features

Default page content

• $ left- region. Contains the html code for the left column. If you specify any regions in the info file, it disappears
• $ breadcrumb - "bread crumbs" for current page
• $ title- page title
• $ help- dynamic tips, mostly shown in the admin panel
• $ messages- displays messages about errors and warnings on the site
• $ tabs- links (tabs) connecting the current page with its subpages (for example, for an article - with its edit page)
• $ content- content of the current page
• $ right- region. Contains the html code for the right column. If you specify any regions in the info file, it disappears

Bottom area / covering data

• $ feed_icon- line with all icons feedback for the current page
• $ footer_message- message at the bottom of the page. Configurable at mysite.ru/admin/settings/site-information
• $ footer- region. Contains the html code for the bottom of the page. If you specify any regions in the info file, it disappears
• $ closure- closing label for all modules that changed the page. This variable must be displayed after all dynamic content. Best before closing the BODY tag

All are listed here standard variables... But you can add your variables here either as regions through info-file, or in any other role via file template.php(about him a little later).

Now I will show you what code should be in page.tpl.php and into what code it is then interpreted by browsers. Here is a piece of code from page.tpl.php:

The first line checks whether the current page has a title at all. If it is not there, then the debugger will simply skip this code and will not enter it. If the title exists, then the tag will be added to the html code of the page

, after it the page title will be printed, and all this will be closed with the tag

... If you look at the code of this page in a browser, then it would look like this:

Lesson 4. Required files to create a template. Page.tpl.php

Almost all site variables are wrapped this way. This is done so that we can style the content without knowing in advance what it will be.

This is how it looks standard file page.tpl.php that comes with Drupal. Change the name of the classes, rearrange the variables - and see what happens. This is necessary in order to "feel" how it works and what is displayed as a result.

"- // W3C // DTD XHTML 1.0 Strict // EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> "http://www.w3.org/1999/xhtml" xml: lang = "language?> " lang = "language?> " dir = "dir?> "> "" >

Separating the logic of receiving data from the logic of their display is a very important part of web development.
Any programmer who has risen slightly above the "Hello world" level begins to feel the need for such a separation. But not everyone comes to the right conclusions and decisions.
Therefore, here are the most important rules:
1. The receiving code and the data display code must be separated.
2. Any output should begin only after all data is ready for it.
3. As a consequence, any script should only deal with data processing. After that, he can either send some kind of HTTP header, or call the template, passing it the prepared data, or both together.
4. Which template engine to use is the tenth thing. The simplest and most accessible is PHP itself, so examples will be given on it.

Delusions
There is probably no topic in web programming that is as obvious as it is incomprehensible as templates. Everyone, sooner or later, comes to the conclusion that it is necessary to use templates. But it comes, for some reason, through some wildest delusions and fantasies.

The simplest and most obvious misconception is that beginners call a "design" file, which is a common html for all pages of a site, as a template. And on this they calm down. Dynamic information, nothing hesitating, displaying the good old echo :-)
In fact, the template engine is mainly concerned with displaying the changing content of the site pages. And the conclusion of "design" is a secondary task.

There are two main fantasies:
1. The "designer" needs templates so that he can edit them without having to understand PHP.
2. Hence, templates serve to separate PHP from HTML.

Let's try to think about the first statement. What is a designer? This is a person who works in Photoshop. He most often does not know HTML at all. And either a special layout designer or - most often ... the programmer himself - works on the template! Funny, is not it?
Now the corollary, about the separation of PHP from HTML. Fine. We have before us the holy goal of separating. Therefore, we come up with Smarty and write:
(foreach key = cid item = con from = $ contacts)
($ con.name) - ($ con.nick)

(/ foreach)
Even funnier.
The "designer" for whom everything was started faints with happiness.

Theory
It turns out that our reasons why we decided to use templates are not worth a penny. And what now - are they not needed, it turns out, templates in general? Needed. But first you need to answer the question - "why?" For what need templates. And check the answer with practice. I have asked people this question many times. But almost no one can answer it. Why does he need templates. It turns out that people do something without knowing why.
This is the funniest thing.

During my tenure as a web programmer, I have formulated for myself three reasons why I personally need templates. In fact, there are two of them. And ultimately come down to one thing:

One code - multiple views.

It often happens that instead of one information, you need to show another. For example, the code for working with the database receives an error message instead of the news text. In this case, instead of a news page, you need to show a completely different one - with an apology and a request to come back later. It is very easy to do this with templates.

Often the same information needs to be shown in several forms. For example, a regular page and a print page. The information is the same, the retrieval code is the same, and the output code is different. Faced with such a situation, you can very quickly divide your code into two parts, one of which is responsible for the output, and the second is not responsible. Another example: let's say we wanted to output information not directly to HTML, but via an AJAX request, in JSON format. If we used a template engine, then we change exactly one line in our code - calling the template engine to calling json_encode (). And if our output was mixed with the code for receiving data, then the whole code would have to be rewritten!

The situation is somewhat similar: let's say our script is on two sites. Plus a copy at our place. And so we found a big bug at home. Close it up. Now we need to update the code on the sites. And here it is - the moment of truth: if the templates were used correctly, then we simply upload the code to both sites, and everything continues to work, as if nothing had happened! This situation, in my opinion, is an ideal test of the chosen approach to templating.

Another important point that many people miss (in their theoretical reasoning, while constantly encountering it in practice!) - the order of execution of the script does not always match the order of the output in the template... Textbook example - displaying the title of an article in a tag

In the right place, the template of our page (tpl_links.php) is included in it:

• "target =" _blank ">




The easiest way is to create templates based on static pages already laid out in HTML. Let's consider creating and connecting a template using an example. Let's say you already have an HTML file with the following content:

<html> <head> <meta name = "description"content = /> <meta name = "keywords"content = /> <title>title> <link href = "style.css" rel = "stylesheet" type = "text / css" /> head> <body>// start menu<table border = "1" > <tr> <td><a href = "/" > <b> homeb>a>td> tr> <tr> <td><a href = "/ about /"> About mea>td> tr> <tr> <td><a href = "/ me_and_me /"> Me and world dominationa>td> tr> <tr> <td><a href = "/ contacts /"> Contactsa>td> tr> table>// end of menu<h1> Home pageh1> <p> p> <p> Text about me: Text about me: Text about me: Text about me:p> <p> Text about me: Text about me: Text about me: Text about me:p> <p> Text about me: Text about me: Text about me: Text about me:p> body> html>

In order to add a template to the CMS, you need to create a file in the tpls / content directory, for example, test.tpl, and insert your HTML code there. The CSS file should be placed in the css / cms folder and named style.css. It is desirable to put the images in the images folder. Don't forget to change the paths for all images and CSS files.

Comment

Russian letters cannot be used in the template file name!

In order for the system to "see" the new template and start using it to display pages, the template must be added to the system. To do this, go to the settings of the "Structure" module, the "Templates" tab ( http://yourdomain.ru/admin/content/config/ ). You will see a list of already installed templates in each domain that exist in the selected language version.

To connect a new template file, fill in the bottom free line of the fields “ Template name"(Give it some meaningful name, for example" My test pattern") And" File name "(in our case, test.tpl) and click the" Save "button.

If you want this template to be used as the default template, check the "Main" checkbox next to it. This template will now be selected by default in the template selection dropdown. It will also be used to display system pages that use the default template (Registration, Password recovery, Sitemap).

The templates will be visible in the dropdown list when editing each page:

Thus, on one site, you can use many templates at the same time, choosing the appropriate template for both a single page and a group of pages.

Try to create a new page (make sure a new template is selected in the Design Template option) and see what happens on the site.

Your HTML template should appear on the site. But now it is static. Now you need to make it dynamic.

First, you need to determine which parts of the HTML code will change. In our case, the following will change:

window title