eZ Components and PEAR
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
eZ components how to get started?
Its so simply (presumed you have PHP 5.1.0 installed, with 5.1.1 you'll miss some features, we're working on that):
$ pear channel-discover components.ez.no
$ pear install -a ezc/eZComponents-betaAfter that you can include a function defintion like this into your main source file:
function __autoload( $class_name )
{
require_once("ezc/Base/base.php");
// PEAR style autoload, may not work with some PEAR packages!!
if ( substr( $class_name, 0, 3 ) !== 'ezc' )
{
$file = str_replace( "_", "/", $class_name ) . ".php";
$val = require_once( $file );
if ( $val == 0 )
return true;
return false;
}
// eZ components autoload
ezcBase::autoload( $class_name );
}Now you can simply instanciate every eZ component. Documentation can be generated using PHP documentor and a startup documentation (including examples) can be found in your PEAR base path under docs/<ComponentName>/).
Stats
I've quickly searched the PEAR database after knowing what the eZ components can do. There are some more features included in the components, which may not be covered by the PEAR package and the othr way around. Maybe I even missed one here and there or have one too much. At least this overview gives 2 hints: a) If you know PEAR, you know at least, which features you could expect from eZ components. b) If you don't know PEAR you can at least guess from the names, what you maybe can expect and can become curious on both projects. :)
PEAR packages: | 487 |
eZ Enterprise Components: | 19 |
Competing with PEAR packages: | 35 |
ezcArchive:
Archive_Tar: Tar file management class.
Archive_Zip: Zip file management class.
File_Archive: File_Archive will let you manipulate easily the tar, gz, tgz, bz2, tbz, zip, ar (or deb) files.
PHP_Archive: Create and Use PHP Archive files.
ezcCache:
Cache: Framework for caching of arbitrary data.
Cache_Lite: Fast and Safe little cache system.
ezcConfiguration:
Config: Your configurations swiss-army knife.
ezcConsoleTools:
Console_Color: This Class allows you to easily use ANSI console colors in your application.
Console_Getargs: A command-line arguments parser.
Console_Getopt: Command-line option parser.
Console_ProgressBar: This class provides you with an easy-to-use interface to progress bars.
Console_Table: Class that makes it easy to build console style tables.
ezcDatabase:
DB: Database Abstraction Layer.
DBA: Berkely-style database abstraction class.
DBA_Relational: Berkeley-style database abstraction class.
MDB: database abstraction layer.
ezcDatabaseSchema:
MDB2: database abstraction layer.
ezcDebug:
no competetive found
ezcEventLog:
Log: Logging utilities.
ezcExecution:
System_Command: PEAR::System_Command is a commandline execution interface.
ezcFile:
File: Common file and directory routines.
ezcImageAnalysis:
no competetive found
ezcImageConversion:
Image_MonoBMP: Manipulate monochrome BMP images.
Image_Tools: Tools collection for images.
Image_Transform: Provides a standard interface to manipulate images using different libraries.
ezcMail:
Mail: Class that provides multiple interfaces for sending emails.
Mail_Mime: Provides classes to create and decode mime messages.
Mail_Queue: Class for put mails in queue and send them later in background.
ezcPersistentObject:
DB_DataObject: An SQL Builder, Object Interface to Database Tables.
ezcPhpGenerator:
no competetive found
ezcSystemInformation:
PEAR: PEAR Base System.
ezcTemplate:
HTML_Template_Flexy: An extremely powerful Tokenizer driven Template engine.
HTML_Template_IT: Integrated Templates.
HTML_Template_PHPLIB: preg_``*`` based template system.
HTML_Template_Sigma: An implementation of Integrated Templates API with template 'compilation' added.
HTML_Template_Xipe: A simple, fast and powerful template engine.
ezcTranslation:
Translation: Class for creating multilingual websites.
Translation2: Class for multilingual applications management.
ezcUserInput:
no competetive found
Comments