Posts by Tag "ezComponents"

My previous posting discussed different view handlers based on routing information. One example was the PDF View which was implemented rather hackish through overwriting the createResponseBody() function of ezcMvcView. Derick told me the way to go would be writing my own PDF view handler. Since this is a rather lengthy topic I created this new post that only discusses using Zend_Pdf as a View Handler in the new ezComponents MvcTools.

The code for the View Handler would look like the following:

abstract class myPdfViewHandler implements ezcMvcViewHandler
{
    /**
     * Contains the zone name
     *
     * @var string
     */
    protected $zoneName;
 
    /**
     * Contains the variables that will be available in the template.
     *
     * @var array(mixed)
     */
    protected $variables = array();
 
    /**
     * Pdf object to be rendered.
     *
     * @var Zend_Pdf
     */
    protected $pdf;
 
    /**
     * Creates a new view handler, where $zoneName is the name of the block and
     * $templateLocation the location of a view template.
     *
     * @var string $zoneName
     * @var string $templateLocation
     */
    public function __construct( $zoneName, $templateLocation = null )
    {
        $this->zoneName = $zoneName;
    }
 
    /**
     * Adds a variable to the template, which can then be used for rendering
     * the view.
     *
     * @param string $name
     * @param mixed $value
     */
    public function send( $name, $value )
    {
        $this->variables[$name] = $value;
    }
 
    /**
     * Processes the template with the variables added by the send() method.
     * The result of this action should be retrievable through the getResult() method.
     */
    public function process( $last )
    {
        // template method
    }
 
    /**
     * Returns the value of the property $name.
     *
     * @throws ezcBasePropertyNotFoundException if the property does not exist.
     * @param string $name
     * @ignore
     */
    public function __get( $name )
    {
        return $this->variables[$name];
    }
 
    /**
     * Returns true if the property $name is set, otherwise false.
     *
     * @param string $name
     * @return bool
     * @ignore
     */
    public function __isset( $name )
    {
        return array_key_exists( $name, $this->variables );
    }
 
    /**
     * Returns the name of the template, as set in the constructor.
     *
     * @return string
     */
    public function getName()
    {
        return $this->zoneName;
    }
 
    /**
     * Returns the result of the process() method.
     *
     * @return mixed
     */
    public function getResult()
    {
        if($this->pdf instanceof Zend_Pdf) {
            return $this->pdf->render();
        } else {
            throw new Exception("Could not render PDF.");
        }
    }
}

Now you would implement a concrete PDF view handler by extending myPdfViewHandler.

class myConcretePdfViewHandler extends myPdfViewHandler {
    public function process( $last ) 
    {
        $pdf = new Zend_Pdf();
        // do concrete PDF drawing stuff here
 
        // save PDF here, will be rendered in getResult()
        $this->pdf = $pdf;
    }
}

And your ezcMvcView implementation will make of createZones() and look like the following:

class myPdfView extends ezcMvcView {
    function createZones( $layout )
    {
        $zones = array(); 
        // A decision which concrete Pdf Handler should be used would be decided on here.
        $zones[] = new myConcretePdfViewHandler( 'concreteA' );
        return $zones;
    }
}

There you go!

I have written on the new ezComponents MvcTools component before already. Just yesterday the beta of this component was released with the general beta of the 2008.2 version of ezComponents. Several bugfixes and enhancements were included into the MvcTools which make it a perfect component for any Mvc based application.

I reviewed lots of the code myself and can only say i love the beauty of the code. Its very simple but by default the most powerful mvc solution in the PHP market. People working with unittests will like it very much, since all the parts are perfectly separated from each other allowing to test controllers, views, routers and filters in complete separation.

To show one very simple example howto benefit of the seperation of view and controllers. If we need a view in both html and pdf, this should generally make no difference for the controller. We add two routes, one for the pdf one for the html view that execute the same controller and action:

class myRouter extends ezcMvcRouter{ public function createRoutes() {  return array(   new ezcMvcRailsRoute( '/pdf', 'SomeController', 'index'),   new ezcMvcRailsRoute( '/', 'SomeController', index' ),  ); }}class SomeController extends ezcMvcController{ public function doIndex() {  $result = new ezcMvcResult();  $result->variables['items'] = Model::retrieveLotsOfItems();  return $result; }}

Now howto decide between PDF and Html view? We use the createView method of our dispatcher configuration, but we still only need the http response writer, nothing more.

class myMvcConfiguration implements ezcMvcDispatcherConfiguration { [...] function createView( ezcMvcRoutingInformation $routeInfo, ezcMvcRequest $request, ezcMvcResult $result ) {  if(strstr($routeInfo->matchedRoute, "/pdf")) {   return new myHtmlView( $request, $result );  } else {   return new myPdfView( $request, $result );  } } function createResponseWriter( ezcMvcRoutingInformation $routeInfo, ezcMvcRequest $request, ezcMvcResult $result, ezcMvcResponse $response ) {  return new ezcMvcHttpResponseWriter( $response ); } [...]}

Now both myHtmlView and myPdfView can create their ezcMvcResponse objects that fill the response body depending on their type. Please note that overwritting createResponseBody() in myPdfView is a shortcut that circumventes me having to write a new PDF View Handler (which would be the way to go).

class myHtmlView extends ezcMvcView { function createZones( $layout ) {  $zones = array();   $zones[] = new ezcMvcPhpViewHandler( 'content', '../templates/index.phtml' );  $zones[] = new ezcMvcPhpViewHandler( 'page_layout', '../templates/layout.phtml' );  return $zones; }}class myPdfView extends ezcMvcView { function createZones() {  // empty, abstract method that has to be defined. } function createResponseBody() {  // Set PDF Content-Type Response Header  $this->result->content->type = "application/pdf";  $pdf = new Zend_Pdf();  // do pdf stuff  return $pdf->render(); }}

Now all the the logic that is potentially in the controller is completly seperated from the view handling that may depend on the routing information not on the controller. And views can be tested seperatly from the controller result. Testability is very high.

This years october edition of IPC in Mainz, Germany was the first php conference I have been to. It ended some hours ago and i am quite happy to have been there. I had several great discussions which pointed me to new stuff (to follow) and also met great people.

First thing that completly fascinated me is NetBeans 6.5 with PHP support. It feels much more easy to use than Eclipse PDT. Its faster (from the little tests i could make) and does not strike when you add several large libraries into the include path. It offers much more help on refactoring and organizing than Eclipse PDT does, for example it offers to generate getter/setter, constructor, inheritence methods. Much thanks to Petr who explained to me in detail how NetBeans works.

Ez had lots of people at the conference (to Kore and Tobias i spoke in more detail) and I had some talks with them about ezComponents. This was especially interesting after the great session on object persistence in ez, aswell when I heard that ezcMvc, a model-view-controller component, wil be included in the next release of ezc in Dezember 2008. ezComponents has a Database layer, that does not seem to enforce too much overhead on you but still offers great extensibility through a persistence layer and a library that offers to build Database Diffs. The latter feature is really great and I will definatly have a look at this.

Sebastian Bergmann had a great talk on MapReduce which is an old LISP programming paradigm to work with huge datasets. This style was recently revived by Google because tasks can easily be split and distributed for computing on differend nodes with hundrets of threads. Implementing a working example in PHP is really easy, just finding a good way to process your large data seems to be a topic that needs lots of thinking.

Addtional great things:

• Meet Thomas, the guy that wrote Weaverslave (I use it for years to build simple php applications).
• He is working on a cool open source project Carica Cachegrind with Bastian Feder that will process xdebug cachegrind files via a webinterface (They told me webgrind is actually calculating the numbers wrong).
• Jan Lehnhart and Kore Nordmann had some great things to say about CouchDB.
• Brian Acker talked about Drizzle, which is a forked MySQL that throws out lots of legecy stuff from MySQL out, to build a micro-kernel database server that suites the web.
• Ulf Wendel talked about Mysqli + Mysqlnd. Mysqlnd will be a new internal driver for PHP to access MySQL through Mysqli and optimizes processing and memory consumption. Additionally Mysqli will be extended to offer asynchroneous queries that can be fired at the database and polled latter. To be included in PHP 5.3

Not so good things: There were absolutly to few power lines. People using their notebooks were packed on hotspots where power was available. Please more power plug possibilites next time!