
LiveStreet is a wonderful and favorite system in Habré. However, if you look through the sites created with its help, it’s easy to see that most of them inherit two columns of standard templates.
But LS can boast a simple, but no less functional system of blocks. Why site owners do not use it? Perhaps the matter is in the missing documentation.
This is me today with your help and try to fix it.
Let's start
I will try to tell you about the system of blocks using an example. Sketch a simple test pattern that looks something like this:
')

so:
< div class = "container" >
< div class = "header" >
< / div >
< div class = "content" >
< div class = "leftside" >
< / div >
< div class = "maincontent" > < / div >
< / div >
< div class = "sub-content" >
< / div >
< div class = "footer" > < / div >
< / div >
Block class
Let's start by creating classes for our blocks, which must inherit the system class Block and implement the Exec () method.
Looking at the Block class, you will see that it only accepts the block parameters through its constructor and writes them into the $ aParams property, as well as gives us the opportunity to call the module methods through its wrapper __call ();
Here I will give the code for one of the central blocks. Let him display your latest topics.
< ? php
BlockLast extends block
{
public function Exec ( )
{
$ oUser = $ this - > User_GetUserCurrent ( ) ;
if ( $ oUser ) {
$ aTopics = $ this - > Topics_GetLastTopicsByUserId ( $ oUser - > getId ( ) , 60 * 60 * 24 ) ;
// In order to avoid conflict, create a local view object
$ oViewer = $ this - > Viewer_GetLocalViewer ( ) ;
$ sTopicsLast = $ oViewer - > Fetch ( 'block.topics_last.tpl' ) ;
// Pass the data to the global view object
$ this - > Viewer_Assign ( 'sTopicsLast' , $ sTopicsLast ) ;
}
}
}
Configuration
My favorite part. With the help of the standard LiveStreet config, we will be able to maximally flex the output of our blocks. I will give an example:
// Block created by us in the previous paragraph
$ config [ 'block' ] [ 'rule_topic' ] = array (
'path' => array (
'___ path.root.web ___ / blog / * $' ,
) ,
'action' => array (
'index' => array ( 'blog' ) ,
'new'
) ,
'blocks' => array (
'central' => array (
'last' => array ( 'priority' => 100 , 'params' => array ( ) )
)
) ,
'clear' => false ,
) ;
// Another block that we will describe later
$ config [ 'block' ] [ 'rule_user' ] = array (
'path' => array (
'___ path.root.web ___ / profile / * $' ,
'___ path.root.web ___ / settings / * $'
) ,
'action' => array ( ) ,
'blocks' => array (
'upper' => array (
'block.user.tpl'
)
)
) ;
As you can see the configuration of the blocks is a rather trivial task. The names of the parameters speak for themselves, so they will not have to understand them for a long time.
- path - the key contains an array of patterns. If the current address of the page matches the pattern, the block is displayed.
A few notes:
- The rules described in the path are checked only if the action key of the configuration is not passed or there is no current Action in it.
- The symbol "*" is replaced by "[\ w \ -] +" when preparing a pattern. The forward slash character "/" is escaped.
What is replaced by "___ path.root.web ___" I think you guessed it. No further actions are taken with the template before the check.
- action - the list of Actions for which the block will be added.
On the example of the first block, it is also clear that the elements of the array can themselves be an array, specifying to which Event of the selected Action the rule applies.
I note that in case you don’t pass the action key in the configuration array, PHP will issue a pair of Notice.
Therefore, if you have determined all the block behavior using the path key, you can simply pass an empty array.
- blocks - defines blocks for output.
I want to draw your attention to the fact that you can transfer not only the name of the block class, but also the block template * .tpl in the block array. What is useful. if you just need to place several lines of text (in the configuration above, we determine that our last block belongs to the central block group, and the upper group will contain the block specified by the template file block.user.tpl).
Additionally, you can set the block output priority and call parameters (these are the parameters that will be passed to the block constructor and written to the $ aParams property).
- clear - if the key is set to true, all blocks already added to the current group (in our case, central ) will be removed from there.
Template
The easiest step. The system will automatically search for a template for our block at the address _path_to_sablon_ / block._block_name_.tpl
For the
topics block, we passed the $ sTopicsLast variable to the template. Just put it in it.
< div class = "block last-topics" >
< div class = "topics" >
{ $ sTopicsLast }
< / div >
< / div >
For the second block defined in the configuration, we will also create a simple template in the block.user.tpl file
< div class = "hello-user" >
Hi, { $ oUserCurrent - > getLogin ( ) }
< / div >
It remains only to add to the template that I gave at the beginning of the article, the output of our blocks. And again the example with the block we created
< div class = "container" >
< div class = "header" >
< div class = "upper" >
{ include file blocks. tpl sGroup = 'upper' }
< / div >
< / div >
< div class = "content" >
< div class = "leftside" >
{ include file sidebar. tpl }
< / div >
< div class = "maincontent" > < / div >
< / div >
< div class = "sub-content" >
{ include file blocks. tpl sGroup = 'central' }
< / div >
< div class = "footer" > < / div >
< / div >
And finally the blocks.tpl file
{ if isset ( $ aBlocks. $ sGroup ) }
{ foreach from = $ aBlocks. $ sGroup item = aBlock }
{ if $ aBlock. type == 'block' }
{ insert name = "block" block = $ aBlock. name params = $ aBlock. params }
{ / if }
{ if $ aBlock. type == 'template' }
{ include file = $ aBlock. name params = $ aBlock. params }
{ / if }
{ / foreach }
{ / if }
That's all! As you can see the scheme is both simple and flexible.
Thanks for attention!