eZ blog...

Upcomming Summer 2008 eZ & PHP developer events

Wednesday, 21 May 2008, 18:36
Categories: Events
Tags: developer day, eZ Developer Day, eZ Community, eZ Conference, eZ Awards, PHP Vikinger, eZ Publish, summer, events, conference, unconference

A busy week expected in the fourth week of June this year:

eZ Publish Community Developer Day, June 18th, 2008

Tutorials, break-out sessions, talks and presentations, barcamp... some topics announced till now include: performance and testing, improving usability & accessibility in eZ publish, web 2.0, OpenID, integration between ez publish and Ajax frameworks, Open office integration, eZ Components, eZ Find, TinyERP integration, microformats...


eZ Conference & Awards, June 19-20th, 2008

The annual eZ Conference & Awards is the largest Open Source CMS event in Europe. This year marks the 6th annual eZ Conference and new this year is that it will be run together with the Open Nordic Conference and the Open Nordic Mobile event. This is without doubt, the biggest event ever held in Europe with main focus on Free Software.

All together more than 1000 people are expected to join during these days. The program will include keynote sessions, panel discussions and valuable exhibiting.


PHP Vikinger, June 21st, 2008

PHP Vikinger is an unconference directed towards everyone who wants to learn more about PHP and likes to discuss and meet with new people. Unlike normal conferences, the talks at conferences are determined by the attendees, and not a program committee.


Can't wait!

This year will be my first time to join eZ Community during this series of events.

Comments (0)

User-readable cache-block identifiers

Saturday, 10 May 2008, 14:18
Categories: Random thoughts
Tags: cache, cache-block, enhancement, id, eZ cache, identifier

Just as I'm struggling with cache optimization for one of the current projects, I discovered that it would be great if cache-block functionality had one more parameter - a user-defined and user-readable identifier. Being able to clear all the cache by calling this identifier would be a great enhancement. It would be enough if it was implemented at eZ API level, so that users were able to create their own actions (views) to handle it. This would be especially benefitial for caching of custom modules and views, outside content and content tree itself.

Life example: Imagine expensive custom views that require couple of hundreds of SQL queries per view or view/param combination, and can be accessed/managed by a) the owner (of something), b) all other users. Now, leaving these views uncached would be suicidal, and cache-blocks would be quite handy, and there would be only two cache blocks per view (since you either are the owner or not). Now, the additional expectation is that the owner will always have his view up-to-date, which means we can't really cache it for him. Wouldn't it be great to be able to create a button named "Refresh my view", which would cause one particular cache-block (or cache block group) be cleared? In that way, we could cache the owner's view as well, making it possible to let a manual clear only when needed ;)

Comments (0)

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

Tuesday, 22 April 2008, 19:49
Categories: Lab
Tags: variable cache, var cache, cache control, cache layer, viewcache, cache-block, var-block

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.


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:

Comments (2)

Extendable cache definition list for easy extension cache management

Tuesday, 22 April 2008, 15:13
Categories: Extensions
Tags: extensions, clear cache, cache, extendable list, extend, fine-grained cache control

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:

Comments (0)

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

Thursday, 17 April 2008, 07:17
Categories: Events
Tags: eZ developer day, developer day, Warsaw, Bård Farstad, Łukasz Serwatka

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! ;)

Comments (0)