Tobias Schlitt - a passion for php

The yearly International PHP Conference in Frankfurt (or like I usually say: the family meeting) is approaching rapidly and I'd like to invite you to join me in my Hands on eZ Components full day workshop. The session will take place on the first workshop day, which is Sunday the 4th of November, and will provide 6 hours of bundled eZ Components knowledge to you.

At the beginning of this workshop I will give you a general overview on eZ Components, show you the most important concepts and illustrate our architecture and design descisions. After that, we will start digging into code and you will see, how different components work in practice. Using a practical example applications to see working code I will explain to you, you are also invited to make me change it and possible exchange or add a feature and show you a different component. Some of the most interessting components - like Mail, Template and Graph - will be shown in detail and give you a good impression what eZ Components can do for you and how you effectively make use of them. Beside that, I will try to give you some insider tipps and tricks for your daily development and will possibly tab some OO design concepts and patters for explaination.

In addition to these learning aspects of my workshop, it should also give you the possibility to provide us with feedback on what you are missing in eZ Components, what you dislike and what you like about the library. Get into discussion with me and potentially other eZ Components development team members (like Derick and Kore), which will also be at IPC. So, seize the chance and tell us, what you think about our work!

And if you don't have a ticket for IPC, yet, take your heels and register now!

During his keynote on the International PHP Conference 2006 Bray performed a little comparison between Java, Ruby (mainly Rails) and PHP. While I first thought, this could only be some dumb marketing stuff, the presentation was actually really good. Tim first introduced his comparison basis (Scaling, Dev Tools, Dev Speed and Maintainability) and explained his views on the 4 topics and which keywords he considers under each of them. This introduction was really good and well-founded. After that, he showed and explained a diagram to make the actual comparison:

While I agree on his views on Scaling and Dev Tools, I want to criticize the the other 2 points:

Dev Speed:

Surely Ruby on Rails is a fantastic framework, which allows extremely rapid development of web applications. Pure PHP is definitly slower. But while Rails is a Framework for Ruby, he did not consider frameworks for PHP in his exploration. There are lots of frameworks for PHP out there, which can do a lot for you, to rapidly create PHP applications. I never used Cake, but it seems to be quite far grown as a Rails implementation in PHP. Beside that, you have a lot of libraries and frameworks in PHP which follow a different approach than Rails does, but can also speed up your development drastically. Zend Framework, PEAR and not at last our own enterprise component library eZ components, to just name a few.

I think PHP should (almost?) be on the same level with Ruby here.

Maintainability:

There is a huge crowd of crappy PHP applications out there, no doubt here. But anyway, it is quite possible to write well-designed and easily maintainable applications in PHP, too. The reason I think so, is widely covered in the section above. We also have the fitting frameworks and there if you stick to certain paradigms, you can also write well maintainable PHP applications. For the reason that PHP does not force anyone to do this, we might still be behind Rails, but not as much is shown in the chart.

I am of the opinion that PHP and Java are quite equal in this point and are not that far behind Ruby.

But anyway, those maybe just my personal views on the topic and maybe I'm just biased by 6 years of PHP experience. In fact the keynote was really good and I really enjoyed it. Thanks to Tim for being there!

About a month ago it's been the time, where we were about to release the first beta version of the eZ components, the new - new BSD licensed - enterprise open source library. A bit under stress (as usual, who doesn't know) we brought out beta 1, missing some refactoring and unification work, testing and documentation improvements.

Now it's finally done and after a lot of work during the past 4 weeks, we are ready to release the 2nd beta version. A nice christmas present I would say. :)

The feedback on beta 1 was quite positive, at least what I experienced. By I'm sure it will be really good, now. The API of the components has been highly unified, the naming scheme and usage of specific features is smooth and using the classes starts really making fun. I also have to admit, that I never saw a better documented PHP project so far (I could not discover any undocumented element so far).

A deeper impression on what has changed from beta 1 to 2, can be found in the extended version of this entry and in the changelog of beta 2.

To try out the new version of our entrprise component library, simply do
$ pear install -a components.ez.no/eZComponents-beta
if you haven't installed an earlier version, yet, or
$ pear upgrade ezc/eZComponents-beta
if you already have beta 1 installed on your system.

For those of you who do not use the PEAR Installer to manage their eZ components installation, an explicit download package is available here.

I would be glad to receive some feedback on our work, so tell me, what do you geeks out there say?

Finally we managed to release a first beta of eZ systems' new open source product eZ components. As I'm part of the development team, it's a great pleasure for me to see our work becoming ready after all. The project went quite good from my viewpoint, although it was a bit hard to manage work and university in paralell after the great summer vacation time (we have around 2-3 month of free time here).

Some people asked me recently, how I see the eZ components compete with PEAR? My usual answer here is in only very few parts. After one can now see clearly, in which direction the components will go, I see it as a great addition in respect to PEAR, since it manages to combine the best of both worlds. PEAR's approach in the past 3 years (wow, really, Monday was my 3rd anniversary with PEAR) could be described as following:

• Provide a component for almost every imaginable purpose in any imaginable area.
• Provide each component as compatible as possible (PHP 4.3.0, therefore PEAR_Error handling).
• Make the PEAR Installer become the standard in PHP application distribution.

These goals have been reached successfully up to a certain, far grown point, at least with the release of PEAR 1.4, which finally allows to install real applications. As to interpret the first 2 goals, PEAR has become the perfect tool for a rapid prototyping development approach. Once you are used to the PEAR style of coding .o0(...maybe this is why collegue told me recently "yes, because you come from the strange world of pear"...), you can realize a fully working prototype of any custom application really fast.

So good, let's take a look at the approach of the eZ components project:

• Provide a unified, well selected set of rock solid components, which are comonly needed to build a web based application.
• Keep basis of development at the cutting edge PHP version, since this must be frozen when released stable first (Beta1 is PHP 5.1).
• Provide an enterprise approach to a well selected library (open source, but commercial support behind it through eZ publish, if you wish).

And I think the eZ components have reached their goal quite well, too, by now, from both aspects: The open source and the eZ publish point of view.

I don't really have really in depth experience with eZ publish itself, at least I had my hands in 3 customer rojects on basis of eZ publish. From the API point of view, the newly taken component approach will ensure, that development of real applications will become much more convenient on the basis of eZ publish and thererfore that library.

The documentation is much cleaner and the use of OO features is much more convenient. Also, the documentation is on a very high quality level (complete API docs + examples + misc docs) and the test driven development approach should ensure a good amount of start up quality and a solid basis for additional development on it.

While the eZ internal developers and all open source contributors get a well defined starting point for refactoring eZ publish, the eZ publish customizer get a cleaner and more modern API for building large applications and the PHP community get's at least a nice new framework, for companies, this time there is even a company behind it.

So, let's get back to the initial question: How do the eZ components compete with PEAR?. As one can see, both projects follow completly different approaches, and where they collide, the range is pretty small: In the eZ approach, the closed collection has a high priority, therefore we have 19 usuful, stable and consistant components, which compete with functionality of (after a quick search and some brainstorming I counted) about 35 PEAR packages. That sounds like a large number, but only at the first glance, because with today there are 487 packages in PEAR, so the collision rate makes rounded 7% (from a functionality point). Mapped these data to the declared approaches above, one could say that both projects reach theires quite well: The eZ components take a different architectural approach than PEAR overall and reduce the library size (by now) to a minimum. PEAR instead has come close to being a collos of whatever-you-may-need libraries.

The non-competetive part is much more interessting: The eZ components will have their fixed place in the upcoming major eZ publish version (which will end up for you in a highly integrated PHP Application Framework), taking huge parts of the everyday work from your shoulders (user management, content management, and whatever eZ publish can do). On that basis, the development of enterprise PHP applications get's quite comfortable.

But when it comes to customer adjustions, the rapid prototyping approach can come into the game. Most higher level PEAR components are build on a driver based design. Same applies to the eZ components. That will be a real community thing, if people start mixing up both parts in projects and maybe integrate even packages of the libraries. I mixed PEAR with eZ publis in a customer project, where we build the main business logic on PEAR components (namely coding around DB_DataObject) and left all the standard stuff the like front end and user management to eZ publish. Integration with the CMS by now was a bit tricky and needed some experiences (thanks Kore N. ;). That'll be the fine thing about the new version un basis of the components. Both libraries are build so generic, that you can savely take components of both and mix them maybe even up...

So long, with the PEAR Installer, there is another part of PEAR, which is not present in the eZ components. A very good decision on the eZ side was, to take the community approach here and settle on the basis of the new PEAR Installer. I believe that both projects will have a very high benefit from each other. (Take a look at the extended entry to see how to try it out!)

I'm quite satisfied with the work on the eZ components. It's been a very productive process in every direction so far. A very sympatic and competent development team brought members of highly different araes together (from PHP core, eZ publish core through PEAR and C/C++/Java background mixtures). My major feeling, that the approach will have success, relies on the fact, that in the end we all agreed on the design of each of the components and therefore should have taken a very general and inovative approach. Let's see, what the community states after some testing. I'm sure, the feedback will be quite positive (as it was until now, afaik). Anyway, working at eZ systems is real fun, and for that part of my live I reached an important goal in my eyes: I found someone to pay me for exactly what I want to do... Open source! Thanks eZ systems! :)

In the PEAR direction, I have not been that active in the past weeks, which was mainly because the recent milestone of the eZ components project colided a bit with the start of the university winter term. But this should change latest around christmas, when university has some free time again. By now I'm working on an educational project in a way. But more on that later. After that I plan to raise my resources on PEAR again. So, stay tuned and have a good time...

Find in the extended entry:

• eZ components, how to get started
• Quick stats of competing packages

Today I called for votes in the PEAR proposal system for my new package Services_Trackback. If you are reading this and don't know, what a trackback is, please read the MT introduction into trackbacks or the technical specs.

The idea to Services_Trackback was born, when I wanted to implement trackbacks for PEARWeb (which is quite an uncommon idea, since trackbacks normally occur only in weblogs). The idea is, that if someone posts a blog entry about a PEAR package, he will usually link to the package(s) he's writing about. This link should (usually) result in a trackback send try to the given URL. Having those trackbacks registered on PEARWeb allows a comfortable way of having some kind of "link list" for every package, where interessting blog entries are linked.

In the past 4 weeks this has proven in some way, since we currently have more than 40 approved trackbacks on PEARWeb, regarding a range of different packages. Interessting articles like "How to set up your own PEAR 1.4 channel" or "Gentoo PHP Development" have been saved and show actual documentation to the specific packages.

So, back to Services_Trackback. Since tha trackback API is pretty simple in general, one would normal say, that it's not worth a package. But most trackback implementations in today's weblog systems have 3 great problems:

1. Once implemented they usually never get improved.
2. Every weblog system is reinventing the wheel.
3. Most weblogs only support a small range of features for trackbacks (some no autodiscovery, most don't support HTTP redirects,...).

Services_Trackback tries to solve these problems and to centralize implementations of trackbacks, offering a flexible an clear API, a central place to report bugs and improve functionality and a huge set of features. The actual version of Services_Trackback supports:

• Sending a trackback to a given URL.
• Autodiscovering of trackback URLs from websites.
• Allow HTTP redirects when autodiscovering.
• Stepwise strictness settings for URL matching.
• Receiving trackbacks (and responding conform to the specs).
• Generating autodiscovery code for websites.
• Unitested.

My current ideas for further feature extension are:

• Interface to check backtracking hosts against blacklists (SpamCop, etc.).
• Storage interface to store trackbacks to different backends (TXT, XML, database,...).
• Observer interface to observe trackback actions.

This list is of course pretty much extendable by feature requests of users.

Services_Trackback is currently proposed to become a PEAR package and will hopefully be accepted by March 10th. More information, links for documentation and download can be found publically available in PEPr. If you're a registered PEAR developer, please vote for the package here.

Today Stephan Schmidt threw the first public release of his new PEAR package Services_Delicious, which allows to communicate with del.isio.us through PHP pretty easily. His announcement shows a pretty little example. Since I'm currently on a del.icio.us trip (I recently migrated all of my bookmarks there), I like that thing pretty much, also I did not come to try it out, yet.

What would be pretty cool are some plugins for this sweet weblog application I am using. Imagine (*throwing some meat to the S9Y corner*):

• Directly adding your entry to del.icio.us while posting.
• Direct integration into the sidebar, with customization through the admin environment.
• ...

Through a blog entry by Urs Gehrig I came to a nice little PHP script, the so-called libgmailer. This little class provides easy access to the Gmail interface through PHP. It supports all necessary methods to send and receive emails, to browse folders and manage contacts. Since everyone has a Gmail account now and most of the people I know do not really use it, libgmailer is a funny way to maybe get some benefit out of Gmail.

Finally after trying, I asked the Author to provide the class into PEAR (which is currently not possible, because of it's license), but maybe that works sometimes.