ZF2 + Blitz templates

Hello, my dear habrovchane. And if any of you are engaged in web development in PHP, then generally welcome. I began to look at various frameworks just now ... We divorced them in PeHaPe - a passion. Apple has nowhere to fall, as they say blondes.



I remembered here that once upon a time (when DOM-trees were large, and Unicode was single-byte) I made a tiny commit to Zend Framework (then only the 1st version was). Let me think, see - what lives, what Zend breathes today. I looked - I grew up somehow ... matured ... And I remember him like that… I began to read what will happen next , and also an article about PSR-7, HTTP Messages and their implementation in PHP . Holy Fathers! We must continue to look, we must learn, learn and learn. And then a young pimp will come, and how will he wipe me from the face of the Earth:


')
All had to learn again. He groaned, went through the Getting Started Quest Guide , thought. I didn't like something in all this. Maybe the dark words "Skeleton Application" at the top? Or the fact that the config for Nginx had to write itself (what are they poking me with their Apache Harey in the face?). No, not that ...

ABOUT! There after all in ZF2 template engine for PHP!



Over the years in Badoo, Blitz templates have become familiar and familiar. It is necessary to fasten them here urgently. Googled - no. What the hell?? (probably bad google?) In general, I cleaned the XDebug scalpel , took cotton, alcohol and a cucumber, and began to dissect.



The patient was a learning app . More precisely, its fork .

Tak-s, let's see, see ... What is a patient's healthy liver, you do not find, colleague? Though in the coffin of luggage ... Here we will transplant it. By cookie, I mean the implementation of the RendererStrategy from Zend View Quick Start . Take the class AcceptStrategy and copy to yourself. Let's call a copy, as usual, Poluekt. Just kidding, let's call Application \ View \ RenderingStrategy . Why not BlitzRenderingStrategy ? Yes, of course, it creates and adjusts our rendering engine, which means it will also, for example, customize the rendering of JSON, in the case of a corresponding request. So here.

In the resulting class, I amputated the “xxxRenderer” properties — why do we need them right away? Well, to have Zendovsky ServiceManager on hand, I decided to pass it on to the constructor:

/ **
* @param ServiceManager $ sm
* /
public function __construct ( ServiceManager $ sm = null )
{
$ this -> sm = $ sm ;
}

selectRenderer () and injectResponse () had to be rewritten. That's what comes to it!

/ **
* @param ViewEvent $ e
* @return \ Zend \ View \ Renderer \ RendererInterface
* /
public function selectRenderer ( $ e )
{
$ model = $ e -> getModel ( ) ;
if ( $ model instanceof JsonModel ) {
return $ this -> sm -> get ( JsonRenderer :: class ) ;
}

return $ this -> sm -> get ( BlitzRenderer :: class ) ;
}

/ **
* @param \ Zend \ Mvc \ MvcEvent $ e The MvcEvent instance
* @return void
* /
public function injectResponse ( $ e )
{
$ renderer = $ e -> getRenderer ( ) ;
$ response = $ e -> getResponse ( ) ;

if ( $ renderer instanceof JsonRenderer ) {
// JSON Renderer; set content-type header
$ headers = $ response -> getHeaders ( ) ;
$ headers -> addHeaderLine ( 'content-type' , 'application / json' ) ;
}

// Inject the content
$ response -> setContent ( $ e -> getResult ( ) ) ;
}

Something for a long time there were no pictures.



Here it is. Already a whole class did! But this was not enough! It is also necessary that our “module” (the word for which is the module module) know that we are preparing for it! No, what's a goose, eh ?! This all happens in the class Application \ Module

/ **
* @param \ Zend \ Mvc \ MvcEvent $ e The MvcEvent instance
* @return void
* /
private function registerRenderingStrategy ( $ e ) {
$ app = $ e -> getTarget ( ) ;
$ locator = $ app -> getServiceManager ( ) ;
$ view = $ locator -> get ( \ Zend \ View \ View :: class ) ;
$ renderingStrategy = $ locator -> get ( RenderingStrategy :: class ) ;
// Attach strategy, which is a listener aggregate, at high priority
$ view -> getEventManager ( ) -> attach ( $ renderingStrategy , 100 ) ;
}

public function getServiceConfig ( )
{
return array (
...
'factories' => array (
RenderingStrategy :: class => function ( $ sm ) {
/ ** @var ServiceManager $ sm * /
return new RenderingStrategy ( $ sm ) ;
} , ..
) ,
) ;
}

Well, a little change onBootstrap () in the application module:

$ eventManager -> attach ( 'render' , function ( $ e ) {
/ ** @var \ Zend \ Mvc \ MvcEvent $ e * /
return $ this -> registerRenderingStrategy ( $ e ) ;
} , 100 ) ;

What else to add? I decided that it was not worthwhile to save Blitz templates with the .phtml extension, and before the heap I changed the config file:

'view_manager' => array (
...
'default_template_suffix' => 'blitz.html' ,
) ,

Well, I also had to change the controller code a bit where the result of the database sample is transferred to the view: Blitz does not support all these new-fashioned iterators, give it arrays (our grandfathers programmed without iterators, and we will! Really, fisher ?) , that if you call toArray () on the ResultSet instance, then it will call the same toArray () on each row. I had to supplement the Album model with the toArray () method. And, well, I had to translate the templates to Blitz and save it with the suffix "blitz.html".

I do not even know how bad this way of integrating the template engine in ZF2. Maybe professionals know a clever way? Discuss?