• Search:



Planet eZ publish




graham brookins

› eZ Authorize released to the eZ publish community

eZ Authorize adds flexible credit card capture and authorization to eZ publish 3 e-commerce shops.

Brookins Consulting is very proud to offer the first e-commerce payment solution to designed for eZ publish 3 and Authorize.Net

04/12/2005 6:56 pm (UTC)   Graham   View entry   Digg!  digg it!   del.icio.us  del.icio.us

graham brookins

› eZ Authorize ¦ 1.0

eZ Authorize 1.0 has been released to a select few for testing, review and comments before it’s public release. Update: We are ready to start the first release. We will begin to trickle release eZ Authorize (v1.0.0) via our site, on the solutions icon. Next we will migrate development and release code for both eZ [...]
04/12/2005 7:18 am (UTC)   Graham   View entry   Digg!  digg it!   del.icio.us  del.icio.us

php developer

› Community News: PHP-Qt Project - Cross-platform GUI Development

Via this new post on Nexen.net, there's information about an extension that's looking to provide another cross-platform solution to the creation of local GUI software with PHP - PHP-Qt.

PHP-Qt is an extension for PHP5 that aims to write software with the Qt Toolkit. It provides an object-oriented interface to the Qt4 Framework and allowes to write Qt applications in the PHP language.

Qt by Trolltech is a C++ toolkit for cross-platform GUI application development. Qt provides single-source portability across Microsoft Windows, Mac OS X, Linux, all major commercial Unix variants, and embedded Linux.

Their first (and latest) release, version 0.0.1, has been posted and is ready for some testing. You need to have PHP 5.1RC1 or later to get it working (as well as the Qt4 development files, of course), but it looks like it has some good potential...

02/12/2005 2:18 pm (UTC)   PHP Developer   View entry   Digg!  digg it!   del.icio.us  del.icio.us

php developer

› Professional PHP Blog: The rumors of PEAR's demise are greatly exaggerated

From the Professional PHP Blog today, there's this new post with his perspective on the whole PEAR vs. eZ Components debate that's been going on.

Tobias Schlitt has a lengthy comparison of the new ezComponents and PEAR. He goes to great lengths to show that ezComponents and PEAR do not compete.

I've also seen some ill informed speculation that Zend PHP Framework will kill off PEAR. Um, not gonna happen. PEAR is a library, not a framework. Well, PEAR is a repository of libraries, not a framework. Well, I don't know what PEAR is, but its not a framework.

He also makes mention of the definition of a framework and, maybe, just maybe, compares it to the eZ components ("a reusable design for a specific class of software").

Do you agree? What's your take on the eZ components? Have you worked with them?

02/12/2005 1:45 pm (UTC)   PHP Developer   View entry   Digg!  digg it!   del.icio.us  del.icio.us

alberto mucignat

› eZ components (i miei due cents)

È stato rilasciato eZ components, un framework php per la creazione di applicazioni web. La notizia è abbastanza importante, perchè si tratta, PEAR a parte, di un evento eccezionale. Il framework è stato rilasciato dall'azienda che produce eZ publish ed è basato su una nuova licenza BSD, ovvero una licenza che da la possibilità di utilizzare il software anche per applicazioni commerciali senza dover pagare alcuna fee.

Perchè questa notizia è un evento? Perchè eZ systems brucia sul tempo Zend, l'azienda che guida lo sviluppo di PHP e che aveva annunciato il lancio di un proprio framework.

C'è già chi inizia a fare confronti, ma secondo me il discorso è un altro. Nella homepage del nuovo progetto di Zend c'è un bel riferimento al neonato eZ components, segno che le due aziende non sono per niente in contrapposizione come si potrebbe pensare.

Un bel colpo è stato assoldare un Tobias Shlitt per fare il porting del framework su PEAR, come spiega lui stesso.

Un altro colpo da 90 è stato utilizzare un metodo di sviluppo test-driven per il framework. eZ Components è basato su PHP5 (quindi OOP) e costituirà l'ossatura su cui verrà sviluppato eZ publish 4, che sarà il porting di eZ su PHP5.

Se ne parlerà ancora, imho. Intanto, su technorati.
01/12/2005 7:43 pm (UTC)   Alberto Mucignat   View entry   Digg!  digg it!   del.icio.us  del.icio.us

php developer

› IBM developerWorks: Debugging techniques for PHP programmers

In this new article from the IBM developerWorks site today, there's a look at doing some debugging with the help of a debugger extension for Eclipse - PHPExclipse.

This article details various methods for debugging PHP applications, including turning on error reporting in Apache and PHP, and by placing strategic print statements to locate the source of more difficult bugs through a simple example PHP script. The PHPEclipse plug-in for Eclipse, a slick development environment with real-time syntax parsing abilities, will also be covered, as well as the DBG debugger extension for PHPEclipse.

step you through the installation, how to turn on the error reporting correctly, and how to use the real-time features in Eclipse to make your life easier. Throw in the internal debugger, and you just about have a match made in heaven...

01/12/2005 2:36 pm (UTC)   PHP Developer   View entry   Digg!  digg it!   del.icio.us  del.icio.us

php developer

› DevShed.com: The Singleton and Factory Patterns in PHP - Working With Singletons

DevShed.com has posted part four in their "The Singleton and Factory Patterns in PHP" series today - "Working with Singletons".

In this fourth part of the series covering the Singleton and Factory Design Patterns in PHP, we will discuss issues stemming from the fact that PHP 4 does not have an abstract class. Since we found it useful in the previous article to define the form element factory class as an abstract class, in this article we will discuss the process for making the form element factory class a Singleton, and how this serves our purposes.

They walk you through the process of using the Singleton pattern, including how to make it all work in PHP4. They keep with the form creation example, and show how to interlace the pattern with it...

01/12/2005 2:31 pm (UTC)   PHP Developer   View entry   Digg!  digg it!   del.icio.us  del.icio.us

php developer

› Tobias Schlitt's Blog: eZ Components and PEAR

On Tobias Schlitt's blog today, there's this new (lengthy) post with his answer to a question he's been asked more and more lately - "How do you see the eZ Components competing with PEAR?".

Finally we managed to release a first beta of eZ systems' new open source product talks about the goals of each project - noting that each has seemed to achieve them - but also noting that they differ slightly in their current structures. PEAR is a more open, less regulated network of components, where as the eZ systems components are monitored and focused. It's interesting, too, that the eZ folks decided to go with the PEAR Intaller for their system as well...

01/12/2005 2:26 pm (UTC)   PHP Developer   View entry   Digg!  digg it!   del.icio.us  del.icio.us

tobias schlitt  eZ systems employee

› 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

Continue reading "eZ Components and PEAR"
01/12/2005 10:56 am (UTC)   Tobias Schlitt   View entry   Digg!  digg it!   del.icio.us  del.icio.us

tobias schlitt  eZ systems employee

› 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

Continue reading "eZ Components and PEAR"
01/12/2005 10:56 am (UTC)   Tobias Schlitt   View entry   Digg!  digg it!   del.icio.us  del.icio.us