Over the last few days, I finally decided to revisit the old OSInet PHP library, to dust it off somehow, and convert the class-based parts to PSR0 and the whole to what seems to be liable to become PSR1 at some point.

This library contains a zoo of function helping with PHP-GTK development, and three packages with their demo application:

Class Grapher

Build a graph of inheritance and interface implementations on a directory (and subdirectories) of PHP code

This package uses the Drupal Grammar Paser to parse code, and includes a Drush 5 plugin for easy use within a Drupal site, but can also be used to parse non-Drupal code, as long as the Grammar Parser - which does not depend on Drupal either - is installed in the include path.

It is a more complete version of the Drupal-only Class Grapher sandbox on drupal.org.

In the current version, graphs are generated using GraphViz. An extension to a client-side visualization tool like the Infovis toolkit should come someday. Suggestions for other client-side libraries welcome (please comment!).

Open Document Calc reader

This package provides a few classes and methods to extract the content of OpenDocument (LibreOffice, OpenOffice.org, ...) spreadsheets.

Finite State Machine

This package is used to build applications designed around a finite state machine, and is mostly intended for use in PHP-GTK applications, to provide asynchronous processing.

The demo application uses the PHP FTP extension to expose its asynchronous notifications in a PHP-GTK UI

After recent complaints in the PHP-GTK mailing list, auroraeosrose mentioned mgdm has set up a SVN repository for the docs, to ease working on them.

This new repository is available at
http://svn.thefrozenfire.com/phpgtkdoc/

I just found out a very strange PHP feature by browsing the PHP-GTK2 API with the Reflection classes : spaces can be used in some alien places, like variable names.

But the doc says you can't !

Well, try this in PHP 5.2.5, for instance:

With OSInet having a large part of its business with suppliers and customers within the EU at large, I often find myself having to check the validity of the VAT information for third parties, and the EU VIES database comes in handy.

However, although I had been discussing remote access using XML-RPC or SOAP as early at 2004 with the database administrators, the UI had remained web 1.0-only until quite recently (apparently march 2007), when an AXIS SOAP service went online, just as I had suggested three years ago. So I figured I really couldn't let the occasion pass, and did a PHP-GTK client to VIES, which happens to be my first production SOAP application in PHP-GTK, previous ones having always been done in Pascal using Delphi or Kylix.

Let's see how this can be done... (code updated 2010-09-21)

I had been in need of a class to read config data into both the PHP-GTK OSInet back-office front end, and the back-office client UI for the Drupal 5.x offload module, and hesitated between various solutions, ranging from roll-our-own to the various frameworks out there and the existing PEAR packages.

Since Zend Framework appears to be well on its way to becoming a standard for professional PHP developers, I figured I'd give it a spin :

A discussion these days on the PHP-GTK general mailing list revolved around the issue of feeding a large amount of rows to the model bound to a GtkTreeView.

The PHP-GTK community site has been running on Drupal 5 betas since its creation one month ago, and I thought it really needed a live chart of statistics to match its glorious Garland dress, and GD would allow it. But how does one go about creating charts within Drupal ?

.

A few days ago, I was glad to learn that this blog had been included in the Planet PHP blogroll. And today, when checking the news, what did I see ?

The problem: while coding PHP-GTK apps, the most elementary debugging method is to use echo or print statements. These are fine and dandy for english or usonian coders, but may be a problem for coders elsewhere around the globe, since PHP scripts are typically stored under UTF-8 encoding to limit i18n headaches, while the console in which their output will be displayed is normally configured to some regional encoding, like IBM850 in Windows/XP French.

So we need a workaround...

The new Drupal-based community site for PHP-GTK is up at http://www.php-gtk.eu.

Drupal features

Technically, this is pretty much a plain Drupal 5.0 Beta 1 Beta 2 RC1 RC2 site, using the new Garland theme without custom changes besides a much needed fix, and a site-specific module for things like useful referer counting and the PHP-GTK dev geolocation service.