Geekly Articles each Day
⬆️ ⬇️

methods of working with the template engine

The nested template should set the title.



most often encountered such a problem: in the middle of the page a block is displayed, this block sets the Title, but really the Title is already displayed in the head, how to be?



solution (Thanks to AlexHamp)



discard the idea of ​​the footer and header, and proceed to the idea of ​​nested blocks. The problem of pregeneration of nested blocks remains, it is solved this way: first, we generate the contents of nested blocks and set the title to them, and then output them in the main page template.



page template: 

 {assign var = "pageTitle" value = "My Site"}
 {if! empty ($ innerTemplate)}
	 {include file = $ innerTemplate assign = "innerContent"}
 {else}
	 {assign var = "innerContent" value = "no nested template"}
 {/ if}

 <Html>
 <HEAD>
     <TITLE> {$ pageTitle} </ TITLE>
 </ Head>
 <BODY>
 {$ innerContent}
 </ Body>
 </ Html>


Now internal template: 

 {assign var = "pageTitle" value = "My Site: News"}
 <h1> News </ h1>
 ... further output news ...


')

If we work with the Quicky type template engine, with a common namespace, then this is quite enough; if we work with Smarti, then the following should be done in the script: 

 $ pageTitle = ";
 $ smarty-> assign_by_ref ('pageTitle', $ pageTitle);


Now changes in the internal template will occur with $ pageTitle from the script, the output will be carried out by her.



Thus, we were able to transfer the task of generating headers to an internal template.



Generating data in a template?



I guess you thought: “right now, we will be shown the spaghetti code, and we will shower this guy with tomatoes!”. But I hasten to stop you! it will be a question of solving the problem of associating a map and a model with an acceptable separation of these. Often it is necessary to introduce a block everywhere on the site, perhaps an informer, take for example a block that is displayed next to the user's nickname (all messages, comments and all everyone!) And displays a little information about it (let's say just the registration time, and username ). Of course, some gurus will say: use the generation of this data directly in the model! in each place where you generate these user logins, generate and related information! I agree with you, and even add, if you can’t do it, then the project’s architecture begins to smell bad, but we often need to work in non-ideal conditions, and sometimes we need a solution that doesn’t force us to rummage, for example, in someone else’s code , or in the "black box". How to write an extension? the first thing that comes to mind is to write a function and register it in smarti then call it, for example like this: {getUserRegDate userlogin = $ login} if we need a lot of related information, then the solution will be cumbersome.



I suggest doing this:

to declare a class that will access the information, to include all the logic in it according to how information is extracted. 

 class UserInfo () {
     public $ regDate;
     public $ iniciateStatus = false;
     public iniciate ($ login) {
         if (read login details) {
            take the data and write it into our container
            $ this-> regDate = ...
            $ this-> iniciateStatus = true;
         } else
              $ this-> iniciateStatus = false;
     }
 }


and connect it 

 $ smarty-> assign (new UserInfo (), $ userInfo);


now how to use it in the template? 

 {if $ userInfo-> iniciate ($ login)}
     registered {$ userInfo-> regDate | date_format}
 {/ if}




Now all this should be encapsulated in a subpattern-block and called like this: 

 {include file = userInfoBlock login = $ login}


As a result, we get a fairly elegant solution to the problem of requesting data in a template from the model, minimally mixing them.

This is necessary, for example, when in the process of working with the template itself we learn that we need some other data from the model. And, as my practice has shown, this does not always indicate a bad system architecture.



UPD

If you do not like without control access, you can limit it:

in iniciate, we do assign data and in the template we write easier:

{if $ userInfo-> iniciate ($ login)}

registered {$ userRegDate | date_format}

{/ if}



true so you can get a name conflict.

Source: https://habr.com/ru/post/45258/

More articles:



All Articles