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

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

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

There will be many situations when creating web forms, that either you cannot accept all data on one page, either because certain responses result in a different set of subsequent questions, or because you form is so long that you need to split it up into multiple pages.

This tutorial covers how to implement such forms using PHP. This will include covering the various issues that need to be taken into consideration, as well as a class to help build such forms. Finally, there will be real-world example of implementing a multi-page form using the class.

He shows you the creation process using his own "lightweight Wizard class" instead of a standby like PEAR's QuickForm for structural reasons. QuickForm works great for single-page forms, but trips up a bit when it comes to more than one. He talks about considerations you'll need to take, and provides the code for his "ZervWizard class"...