piotr karaś

› Variable cache layer... Var-block - wouldn't that be something?

It took me fairly long time to figure out what particular tool available from PHP in my custom software and website implementations was missing from eZ Publish... but I finally got it. It's the ability to dynamically, flexibly cache variables, understood as operation or logic results, stored in a reusable form. Naturally, there is no significant need of caching simple variables defined directly within the pagelayout, just like these:

{def $my_var=345}
{def $my_other_var=hash( 'a', '4023' )}

However, it gets worse not being able to cheaply store an array of ten values, whose fetching/generating cost was over fifty or one hundred SQL queries, several files accessed in the file system, etc.

Problem

The problem seems quite straightforward - out of many caching techniques and layers in eZ Publish, only two are universally useful: the viewcache and the cache-blocks. Unfortunately, both of them store presentation layer results rather than data, and both are quite independent. As a result:

  1. Whenever you crave for variables that will be used by several cache-blocks in the pagelayout, they must be placed outside of cache-blocks themselves. Don't get fooled by the top cache-block apparently holding the variables used further on - it's a coincidence. This may only work if all expiry times are equal for all the blocks and no subtree expiry is ever used (or you've used bugged eZ 4.0.0 for half-a-year, where subtree expiry is simply broken and it's easy to take it as the default behavior), provided that the blocks never got desynchronized. The point is: variables must be kept outside cache-blocks and they will not be cached.
  2. The module result gets generated before the pagelayout, so there's little reusability between their vars.
So what's missing?

My idea is a cache layer halfway between logic/data and the presentation layer. It could be a variable-dedicated cache-block equivalent (maybe a var-block?).

Example: Imagine a website that for each of its node views should be able to access both current node data (data map) as well as root node data in order to make some decisions, calculations, etc. Further, the data could be required by at least three of its cache blocks (with different expiry times, expiry rules and "uncomfortable" locations within the pagelayout). Today that sort of combination requires a substantial...

The var-block as I imagine it would have expiry settings similar to cache-blocks: subtree expiry, expiry ignore, expiry time and a flexible key management. In order to prevent frequent file system access, var-block could serialize variable collections rather than just singles. An additional "collection name" parameter could help organize the blocks within the pagelayout.

Please let me know what you think.

Here's the prototype:
http://ez.no/developer/contribs/template_plugins/self_var_cache

22/04/2008 7:49 pm (UTC)   Piotr Karaś   View entry   Digg!  digg it!   del.icio.us  del.icio.us

piotr karaś

› Extendable cache definition list for easy extension cache management

Back after a longer while... wasn't on holiday, though ;)

About a week ago, while developing my fifth or tenth extension with its own, custom caching layer, I caught myself trying to clear that cache with eZ standard "Clear cache" button. To none of my surprise, it never worked, but after few attempts I decided to see why ;)

The Fine-grained cache control in the administration interface turned out to be a definition-type of array - easy enough to be made extensible with some effort. Why should a developer be in need of creating custom tools then? Let's hope the team picks up the idea soon:
http://issues.ez.no/IssueView.php?Id=12860&activeItem=3

22/04/2008 3:13 pm (UTC)   Piotr Karaś   View entry   Digg!  digg it!   del.icio.us  del.icio.us

zak greant  eZ systems employee

› Go Open 2008: People

As usual for a conference, I spent almost all of the time I was at Go Open 2008 talking with people (and occasionally talking at people.) The following is a list of people I talked with (or listened to) along with the interesting or exciting things that they shared with me or that they're working on: The [...]
19/04/2008 1:36 am (UTC)   Zak Greant   View entry   Digg!  digg it!   del.icio.us  del.icio.us

derick rethans  eZ systems employee

› Announcing PHP Vikinger 2008

The PHP Vikinger unconference will be held for the third year in Skien, Norway. Just like previous years it follows directly after eZ Systems conference which puts this year's PHP Vikinger on June 21st, the longest day of the year.

Flickr features some pictures from previous years. And PHP Norge has a report from last year. Let me know (through the e-mail on the PHP Vikinger website) if you're interested, and if you want to suggest topics.

18/04/2008 8:13 pm (UTC)   Derick Rethans   View entry   Digg!  digg it!   del.icio.us  del.icio.us

piotr karaś

› eZ Developer Day - first one in Poland (Warsaw, 15th April 2008)

Polish eZ community has met during the first official eZ Developer Day held in the country. Up to thirty people showed up, representing eZ partners, independent developers as well as users, both experienced and potential. Many of the participants were active Polish eZ Community members. eZ Systems was represented by Bård Farstad, co-funder and CTO (Chief Technical Officer) and our native system developer Łukasz Serwatka.

The meeting, which was held in the heart of capital city of Poland, included the introduction to eZ Systems and their flag products, including eZ Flow (both functional and technical demos), the discussion on eZ Publish roadmap and its future releases.

The community had a chance to present their recent implementations as well as share and discuss their problems or requests (I hope we didn't kill Łukasz during this part, as we tried to clear up issues that had been awaiting "closure" for quite some time).

Bård attempted to provoke some community commitment, so that it grows stronger and bigger, but I'm not sure how much response that would get. It got little while there, but there might be some follow-up. Seems like the active will remain active in their ways anyways.

Personally, I am very glad that we had this meeting. Maybe there was too little technical/developer detail, but everyone had an opportunity to bring things up... Maybe it lacked some social part, during which the community would get to know each other little better and discuss things in a more informal, open way. One suggestion though: make that a weekend event because socializing for most people in Poland hardly ever works during the weekdays! ;)

17/04/2008 7:17 am (UTC)   Piotr Karaś   View entry   Digg!  digg it!   del.icio.us  del.icio.us

xavier gouley

› eZpublish Templates: Easy access to attributes from unknown class

Hi, today, I want to share a good tip to have access to an object attribute of an unknown class from eZpublish templates. This case is rare, but when you have an object with unknown attribute, or from an unknown PHP class, and you want to access an attribute by its name, if the object does not extends a datatype, the classic "object.attribute" operator in template language cannot work. The problem is that this operator call methods like attributes(), hasAttribute($attr) or attribute($attr) to explore the attributes. In your case, the object has no such methods, you cannot modify the class to add them (for some reasons, for example if the object comes from PHP SOAP), and then you need a wrapper to simulate a datatype.

I propose a DummyDatatype wrapper class, used by a template operator, like this :

class DummyDataType {
    var $Object = false;
    function DummyDataType($object = false) {
        $this->Operators = array( 'ddt' );
        $this->NamedOperators = array(
                'ddt'=> array( 'attribut' => array(
                       'type' => 'Object',
                       'required' => true,
                       'default' => null))
        );
        $this->Object = $object;
    }
    function modify( $tpl, $operatorName, $operatorParameters,
                  $rootNamespace, $currentNamespace,
                  &$operatorValue, $namedParameters) {
        switch ( $operatorName ) {
        case 'ddt':
            $this->Object = ($operatorValue != null)?
                 $operatorValue : $namedParameters['attribut'];
            $operatorValue = $this;
        break;
        default :
            $tpl->warning($operatorName,
                   "Unknown operator '$operatorName'");
        break;
        }
    }
    function operatorList() {
        return $this->Operators;
    }
    function namedParameterPerOperator() {
         return true;
    }
    function namedParameterList() {
         return $this->NamedOperators;
    }
    function attributes() {
         $obj = $this->Object;
         $result = array();
         foreach($obj as $key => $value) {
             $result[] = $key;
         }
         return $result;
        //TODO: test this in all cases (string,integer,...)
    }
    function hasAttribute( $attr ) {
         if ($this->Object == false) return false;
         return isset( $this->Object->$attr );
    }
    function attribute( $attr ) {
         if (isset( $this->Object )) {
             if ( isset( $this->Object->$attr ) )
                 return $this->Object->$attr;
         }
         eZDebug::writeError("Attribute '$attr' does not exist",
                        'DummyDataType::attribute');
         $attributeData = null;
         return $attributeData;
    }
}

With this class, used like a template operator in an extension, you can explore an object, whatever his class,
by calling this:

my_object|ddt('my_attribute').0 {* an array *}
my_object|ddt('sub_object')|ddt('a_datatype_object').content...
{* object containing datatype object, with content attribute *}

This class could be useful for some rare cases, but is a smart solution, so keep a bookmark on it ;)

15/04/2008 1:31 pm (UTC)   Xavier Gouley   View entry   Digg!  digg it!   del.icio.us  del.icio.us

xavier gouley

› eZpublish Templates: Easy access to attributes from unknown class

Hi, today, I want to share a good tip to have access to an object attribute of an unknown class from eZpublish templates. This case is rare, but when you have an object with unknown attribute, or from an unknown PHP class, and you want to access an attribute by its name, if the object does not extends a datatype, the classic "object.attribute" operator in template language cannot work. The problem is that this operator call methods like attributes(), hasAttribute($attr) or attribute($attr) to explore the attributes. In your case, the object has no such methods, you cannot modify the class to add them (for some reasons, for example if the object comes from PHP SOAP), and then you need a wrapper to simulate a datatype.

I propose a DummyDatatype wrapper class, used by a template operator, like this :

class DummyDataType {
    var $Object = false;
    function DummyDataType($object = false) {
        $this->Operators = array( 'ddt' );
        $this->NamedOperators = array(
                'ddt'=> array( 'attribut' => array(
                       'type' => 'Object',
                       'required' => true,
                       'default' => null))
        );
        $this->Object = $object;
    }
    function modify( $tpl, $operatorName, $operatorParameters,
                  $rootNamespace, $currentNamespace,
                  &$operatorValue, $namedParameters) {
        switch ( $operatorName ) {
        case 'ddt':
            $this->Object = ($operatorValue != null)?
                 $operatorValue : $namedParameters['attribut'];
            $operatorValue = $this;
        break;
        default :
            $tpl->warning($operatorName,
                   "Unknown operator '$operatorName'");
        break;
        }
    }
    function operatorList() {
        return $this->Operators;
    }
    function namedParameterPerOperator() {
         return true;
    }
    function namedParameterList() {
         return $this->NamedOperators;
    }
    function attributes() {
         $obj = $this->Object;
         $result = array();
         foreach($obj as $key => $value) {
             $result[] = $key;
         }
         return $result;
        //TODO: test this in all cases (string,integer,...)
    }
    function hasAttribute( $attr ) {
         if ($this->Object == false) return false;
         return isset( $this->Object->$attr );
    }
    function attribute( $attr ) {
         if (isset( $this->Object )) {
             if ( isset( $this->Object->$attr ) )
                 return $this->Object->$attr;
         }
         eZDebug::writeError("Attribute '$attr' does not exist",
                        'DummyDataType::attribute');
         $attributeData = null;
         return $attributeData;
    }
}

With this class, used like a template operator in an extension, you can explore an object, whatever his class,
by calling this:

my_object|ddt('my_attribute').0 {* an array *}
my_object|ddt('sub_object')|ddt('a_datatype_object').content...
{* object containing datatype object, with content attribute *}

This class could be useful for some rare cases, but is a smart solution, so keep a bookmark on it ;)

15/04/2008 1:31 pm (UTC)   Xavier Gouley   View entry   Digg!  digg it!   del.icio.us  del.icio.us

maxime thomas

› eZCrop

Still trying to find ways to improve eZPublish, I've thought about a simple process to resize pictures without having to download the picture, to resize in whatever image software and then, upload it again in eZPublish.

My aim is resizing and not scaling. It means that we are losing some information by cropping the picture that we are not losing by resizing. I'm just specifying this point because it's not a extension of the image.ini / image_class mechanism, but a new functionality which allow the user to cut himself a square in his picture. I guess a picture of the result is more obvious :

 

You can download it as usually on ez.no.

It uses a JavaScript library coded by David Spurr and the Scriptaculous library.

13/04/2008 12:53 pm (UTC)   Maxime Thomas   View entry   Digg!  digg it!   del.icio.us  del.icio.us

maxime thomas

› eZCrop

Still trying to find ways to improve eZPublish, I've thought about a simple process to resize pictures without having to download the picture, to resize in whatever image software and then, upload it again in eZPublish.

My aim is resizing and not scaling. It means that we are losing some information by cropping the picture that we are not losing by resizing. I'm just specifying this point because it's not a extension of the image.ini / image_class mechanism, but a new functionality which allow the user to cut himself a square in his picture. I guess a picture of the result is more obvious :

 

You can download it as usually on ez.no.

It uses a JavaScript library coded by David Spurr and the Scriptaculous library.

13/04/2008 12:53 pm (UTC)   Maxime Thomas   View entry   Digg!  digg it!   del.icio.us  del.icio.us

maxime thomas

› eZCrop

Still trying to find ways to improve eZPublish, I've thought about a simple process to resize pictures without having to download the picture, to resize in whatever image software and then, upload it again in eZPublish.

My aim is resizing and not scaling. It means that we are losing some information by cropping the picture that we are not losing by resizing. I'm just specifying this point because it's not a extension of the image.ini / image_class mechanism, but a new functionality which allow the user to cut himself a square in his picture. I guess a picture of the result is more obvious :

 

You can download it as usually on ez.no.

It uses a JavaScript library coded by David Spurr and the Scriptaculous library.

13/04/2008 12:53 pm (UTC)   Maxime Thomas   View entry   Digg!  digg it!   del.icio.us  del.icio.us

eZ publish™ copyright © 1999-2005 eZ systems as