Normally in ZF3 MVC projects, each controller action matches one view and use it to render its output. Occasionally, we may want to build your ZF3 pages by dispatching various controllers from within the matched controller and merging outputs into a unique final view. In this way we can aggregate one or more views to create complex pages like report summaries or widget dashboards. In this post, we will see how to write few lines of code to include output of an arbitrary action into action matched from route.
Zend Service Manager component is Zend Framework’s implementation of service locator pattern. This object is very usefull component for an application and is largely used in ZF applications. Unfortunately in ZF3 default application, Service Manager component is no more available in controllers. An official solution exsists for this, but in this little tutorial, I want to share an easy solution to inject Service Manager in all controllers. To implement this solution, we will write our controllers by extending an abstract controller class written to handle a Service Manager instance.
Sometimes in our Zend Framework 3 multi-language application, we could need to access to Zend Translator component directly from Controllers. For example, when we have to translate a string to return in a JsonModel. So, let’s see how to write a very simple Controller Plugin that will help us to save a lot of code (and time). Following explanation will assume we just have at least a Skeleton ZF3 Application with working Zend Translator component.
Recently I started a new project based on Zend Framework 2, using Twitter Bootstrap as CSS framework. Some days ago, new Bootstrap v3 was released and introduced a lot of changes and improvements. Because of ZF2 Skeleton Application comes out-of-box with Twitter Bootstap 2, I decided to setup the new project skeleton and update CSS framework to latest available release. In this post, I’ll describe the process to update Bootstrap to v3 into a ZF2 project.
The problem Often in a PHP project there could be operations that need to be executed asynchronously. Some example are: processing mail queues, indexing data, computation that requires long elaboration time. A common behavior is handle those operations by using cron to execute processes in background. However, using cron requires expedients to avoid cross executions and forces us to implement some specific procedures and mechanism to store data needed to elaborate.
Problema Spesso in un progetto PHP capita di dover eseguire operazioni in modo asincrono. Alcuni esempi sono: lavorazione di code email, indicizzazione di dati, calcoli che richiedono lunghi tempi di elaborazione. Prassi comune è gestire tali operazioni utilizzando cron per eseguire processi in backgroud. Tuttavia, utilizzare cron richiede espedienti per evitare l’accavallemento delle esecuzioni e ci costringe ad implementare procedure specifiche e meccanismi di stoccaggio dei dati necessari per l’elaborazione.
Yesterday, Evan Coury, Zend Framework contibutor, announced start of Zend Framework branch. Development goals will be merged between ZF team ideas and community suggestions that will be collected in this topic. Anyway, Evan immediatly specifies that development will be focused on avoid dramatic migration as was for transition from ZF1 to ZF2. For all developers that use Zend Framework for their projects, this is the best opportunity to take part to development process and be heard about their needs: power of Open Source.
Scenario Un filtro di Doctrine è uno strumento molto potente che può essere utilizzato per aggiungere condizioni a livello SQL all’interno del nostro gestore di oggetti Doctrine 2. Ciò significa che i filtri influenzeranno il comportamento di query DQL, collezioni, recupero dati, ecc. Come configurare ed utilizzare filtri in condizioni generali è ben spiegato in questo questo articolo della documentazione officiale di Doctrine, ma in un progetto basato su Zend Framework 2, la stessa operazione è un po’ diversa.
Scenario Doctrine filter is a very powerfull tool that can be used to add conditional clauses at SQL level into our Doctrine 2 engine. This means that filters constraints will affect DQL queries, collections, lazy loading, etc. How to setup and use filters in generic conditions is well explained in this article of official Doctrine documentation, but in a Zend Framework 2 project, the same operation is a bit different.
The problem Captcha is a very useful mechanism to avoid automated abuse of your sites and applications. In particular,reCAPTCHA is a Google powered service that offers a free and simple way to implement a captcha protection field in your forms or pages. Zend Framework 2 implements his own components to handle captcha and a specific one to handle reCAPTCHA service. At the moment, the ZF2 documentation is very usefull if you want to integrate a reCAPTCHA in your Zend/Form component, but lacks in describing how to use reCAPTCHA service component alone.