by Mika Tuupola (tuupola@appelsiini.net), Pierre-Alain Joye (paj@pearfr.org)
Currently I'm self employed doing freelance coding. I also maintain and sell the commercial V-webmail which as the name suggests, is a webmail application (available here: http://www.v-webmail.co.uk).
I started off by simply contributing a couple of classes I'd written previously, and it just continued from there. Eventually it got to the point where it was easier to just write my code using PEARs coding standards and styles instead of what I was using at the time.
Currently my favourite would have to be HTML_TreeMenu. It's a kickass set of classes which enable you to easily produce (surprisingly enough) (D)HTML tree menus. You can use it either "manually", building the tree structure in your script or it has recently gained a few import methods so you can import pre-existing tree structures such as my own Tree class, the PEAR Tree class, or possibly most usefully a simple XML file. This last one makes maintenance of navigation tree menus a piece of cake, even for designers(!).
The pros include the obvious wide audience for your work, which in turn brings in free testing and bug reports (and occassionally even fixes). :) I can't really think of any cons; perhaps the initial effort to actually get something "approved", especially if there's already a package with similar functionality (though this does of course help weed out the chaff). Perhaps also the bug reports. ;)
Well V-webmail uses a number of PEAR packages, mostly my own stuff which is in PEAR due to my needing it for V-webmail. There's a few others though including Log, Console_GetOpt and System. I don't rely here though on the PEAR installer, purely to make installation of the application a mcuh simpler affair. Necessary packages are distributed as part of V-webmail and only upgraded as and when necessary. This actually makes life much easier due to the subsequent lack of version conflicts, missing packages etc.
I think that PEAR is currently lacking strong leadership, which will be vital if it is to grow with a consistent set of goals. It could just be something as simple as a few individuals who've been on the project for a significant amount of time, similar in fashion if you like to the php-group, but with focus on pointing the project in the right direction and taking it there, instead of simply administration tasks. That and more top grade code. :)
Thanks to Richard Heyes for this interview.
phpKitchen published a HTML_TreeMenu tutorial (http://www.phpkitchen.com)
phpwebsite (http://phpwebsite.appstate.edu/), a very good CMS has released its 0.9.0 stable. We always like to see a good application that uses PEAR modules as part of its core.
If you come accross PEAR related article article feel free to send (pear-dev@lists.php.net) us the references and they will be added to the weekly news.
www.pearfr.org is a new site dedicated to PEAR. The main
goal is to provide useful tutorials and documentation for a better understanding of PEAR.
These documents are available in french, english, and soon in german.
The merge of the compilation and translation efforts of the official documentation
seems to be no longer one of our priorities.
Feel free to contact them if you think you can help them in translating or writing
documentations or tutorials, even in others langages than the current ones.
Some very good discussions has araised this week about the futur of PEAR. Christian Stocker
wrote a very good resume in the mid-week, he started as follow:
"The intention of PEAR Foundation Classes is to provide well-written,
well-documentated, well-tested and well-extendable code within PEAR and
mark them as such. For becoming a PFC, a class has to follow strict rules.
Users of PFCs can be assured that those class went through thorough
reviewing and testing and therefore should be the first choice for
everyone needing a class for a given task."
You can read the whole thread
here.
Damian Alejandro Fernandez Sosa proposed to publish geographical information about the PEAR developers and to create some sort of world map, that indicates, where the developers live.
DB/ldap2 and DB/ldap3 are DB backends for LDAP V2 and V3 databases. They implement the common DB interface as much as possible, but unfortunately, it is not compatible with the current DB_ldap. However it supports prepare/execute statements (which are powerfull) and is more flexible, as stated by the author, Piotr Roszatycki.
Sandro Zic did a proof of concept converting a XML schema definition to MySQL CREATE TABLE statements with XSLT. A preview is available here. The purpose of this package is to provide several xsd2db stylesheets for various RDMS and LDAP.
Active on CVS this week have been: XML_Parser, MDB, Cache_Lite, I8N, Net_UserAgent_Mobile, DB_ado, Net_DNS. PECL::imagick, DB_DataObject, Mail_Queue, Tree, Spreadsheet_Excel_Writer, PECL::soap, HTML_QuickForm, PECL::myphp, DB_QueryTool and Perm_LiveUser