Portalsuite Function „PrintArticle"

The reason: Up to now the Portalsuite had no instructions how to process article texts. Define a new template for it, e. g., named "article text". This template must not be of the type "article overview template", but has to be of the type "article view". Now you can see, what the distinction of template types is good for. If two templates are defined for a category the Portalsuite decides with this flag, which template shall be used in case of doubt. Please set the category mapping to standard.

Now the article texts can be selected. Please note that now partly other stylesheets are used for the formatting ! Through this the typography of the detailed article view can be defined different from the overview page.

Up to now we allocated a template to each category resp. the Portalsuite automatically used the standard template for all categories no template had been defined for.

You may have already noticed that a global alteration, e. g., at the HTML header, results in necessary alterations of several templates at the same places. So far we had a code redundance in the templates.

A vital feature of the Portalsuite conception is the template segmentation. The segmentation shall avoid redundant code fragments, forward modularity and simplify later changes. Equal code fragments from different templates are hereto relocated into new sub templates.

Let’s take a look at the three existing templates. The beginning is identical in all three templates. For a better overview we ignore the table tag now:

The procedure is simple: We generate a new template, e. g., named "HTMLHead". In case of this sub template the template type and the category mapping play no role and can be left empty resp. undefined. The identical code from the three templates is copied into this new template:

The fact that is no reasonable resp. complete HTML document, is irrelevant as well. The three existing old templates are now changed as follows (exemplarily shown here with the first template only):

The new command "TemplateInclude" includes the sub template "HTMLHead" exactly at that place, where the HTML code and TCC commands stood. The result in the portal preview should be the same. Even the returned source code should be the same as before.

Surely you noticed at once that we do not use any PHP syntax with "<?" etc. for this command, but a syntax deviating completely from PHP: the command is included by curly brackets. This has exclusively technical backgrounds. If we designed the "TemplateInclude" command as PHP function as well, it surely would work as well. But there would have been a serious disadvantage for PHP professionals who want to work with variables and their own complex PHP codes in the templates. A TemplateInclude function would lead to the result that variables are valid only local for each template (Headword "Variable Scope"). For this reason the TemplateInclude was not introduced as a function but in this special syntax. The Portalsuite interprets this command without using the PHP interpreter independently before execution by the PHP interpreter and puts the templates together correspondingly to one big template. This assembled template is then executed by the PHP interpreter. Through this all variables are available automatically, also those, which are defined in the sub templates.

Back to the template segmentation, its advantages and to our example. Exactly considered: First of all the command has an optical effect, the template has become optically shorter. In case of big templates this leads to significantly increased clarity. And this does not only count for that one template, but for all three templates. A further effect: Alterations in the sub template affect all three main templates at the same time. So later changes can be done time-saving and efficient.