Entries by Stephan Schmidt

Today I gave a talk about JSON-RPC Proxy Generation with PHP at the Dynamic Languages World Europe 2008 in Karlsruhe Germany. The presentation covers an introduction to the Proxy and Remote Proxy Design Patterns, JSON in JavaScript and PHP as well as the JSON-RPC protocol specification. Furthermore, the slides also cover the SMD specifications and show how to generate SMD with PHP.

Although Stubbles provides a ready-to-use processor for JSON-RPC and generating JavaScript proxy classes, the presentation takes you through all necessary steps that are needed to implement this on your own.



You can either view the presentation on slideshare.net, or get the PDF in our download area. If you decide to use our implementation, you can find more information in the Stubbles manual.

If you are interested in learning more about applying common design patterns to your applications and are able to understand German, we have good news for you. Your first chance to get information about pattern driven development from the Stubbles developers is the International PHP 2007 Conference in November, where Frank and I will be giving a half-day workshop on PHP Design Patterns. As Frank wrote last month, we are also giving some more 1-hour talks at this conference.

Your second chance to learn more about design patterns is the new German professional PHP training organized by Wolfgang Drews. The course consists of 12 different sessions, I'll be giving the talks about OO developement and PHP design patterns. Other trainers include Christian Wenz, Tobias Schlitt, Kore Nordmann and Tobias Hauser. The best part about this course is, that is an online training and you do not even have to leave the house. More information can be found at the course website or Wolfgang's blog.

If you prefer to read or cannot afford any of the above options, there still is my book PHP Design Patterns published by O'Reilly.

Are you looking for a job? Are you living in Germany? Do you like Java?

If you answer all these questions with 'yes' and would like to work with the Stubbles' developers, than you should apply for a job in my team. We are looking for two Java Web Developers, that are also familiar with XML/XSLT and OOD/OOA. Knowledge of other languages like PHP or Javascript are helpful, if you are applying for this job, as you might end up developing with Stubbles. If you are interested, take a look at the (German) job description.

To ease the deployment of Stubbles applications and new versions of the framework, Frank "invented" the Stubbles Archive (also referred to as STAR). This allows us to create a single file, that contains all PHP class files as well as other resources (like XML documents or XSL templates) that are required by Stubbles in one single file. This file can be included just like you would include any other PHP file:

require stubConfig::getLibPath() . DIRECTORY_SEPARATOR . 'stubbles.php'; // now, the classloader is available and can be used stubClassLoader::load('net.stubbles.xml.stubXMLStreamWriterFactory');
Of course, this does not load all classes in the archive, but just the base classes, that are needed to run the application, by making use of the __halt_compiler() function. All other classes will be loaded from the same file using PHP's stream wrapper API. Of course, this results in a performance loss, but according to our profiling, the loss is minimal.

Greg Beaver and Marcus Börger developed a similar format (based on PHP_Archive in PEAR), but implemented it in C and released it as phar in the PECL repository. Currently, the PHP core developers are discussing, whether this extension should be added to the core in the next version of PHP. Since the announcement of the phar extension, we decided that we will deprecate STAR in favor of phar, once it stabilized and got included into the core. Currently, it seems, that this will not happen in any 5.x version of PHP, so this is another candidate for my PHP 6 wishlist.

I think, it would be a great addition to PHP (from a developer's and marketing point of view) to bundle libraries and applications in one single file and deploy them by copying them to a specified folder. When using STAR for deployment you get a StarClassRegistry, that knowns about all available classes in any STAR-archive that has been deployed. Loading a class from any archive gets extremely easy:

require '/path/to/starReader.php'; include StarClassRegistry::getUriForClass('com.example.MyClass');

The getUriForClass() method scans all archives and will cache the results so they are only scanned once. Having something along those lines backed by a C implementation would be a huge benefit, IMHO. Combining this with namespaces would be great as we finally would introduce unique names for our classes.

And yes, I still know, that PHP is not Java. If I want to develop in Java, I do this at work...

Today, Frank and I did a session about annotations in PHP at the International PHP Conference 2007 - Spring edition. The slides give you an overview, how annotations are used in Stubbles and how you can leverage them in your own application.



A PDF version of the slides is also available on the Stubbles download page.

I'm using static properties quite a lot, often in combination with static classes. This is, where I often encounter a major drawback in PHP. It is not possible to write code like this:
<?php class Foo { private static $bar = new Bar(); public static function getBar() { return self::$bar; } public static function modifyBar() { self::$bar->doSomething(); } } ?>
In PHP. it is not possible to initialize a property with an object.
As long as a constructor is involved, this is no problem, as the workaround is to initialize this properties in the constructor:
<?php class Foo { private $bar; public function __construct() { $this->bar = new Bar(); } } ?>
But how could this be solved, when you never create an instance of Foo but only use static method calls? Continue reading "My wishlist for PHP6, pt4: static initializers"

Yesterday I received the latest issue of the German PHP Magazin. This issue features an article on annotations, that also covers Stubbles extended reflection features. The article gives a short introduction to Stubbles and explains, how to use the annotations of the XMLSerializer component. Furthermore it shows how to create your own annotations in Stubbles.

The second half of the article deals with SOA (Service Oriented Architectures) and shows, how SCA_SDO (a reference implementation of SOA) makes use of annotations to convert components to services and automatically handles dependency injection of local or remote services.

If you are interested in using either of the two projects, consider buying an issue of the PHP Magazin 3.07.

This is just a quick note to tell you that we will be going to the International PHP Conference 2007 - Spring Edition in May. Frank and I will be giving two talks:

• Using the Yahoo! User Interface Library
• Declarative Development using Annotations

We'll provide more details about those sessions and what to expect in an upcoming posting.
Furthermore, my friend Carsten Lucke will be giving two talks at the same conference covering the Zend Framework and PRADO. So this is a great chance for me to meet him and some other people I haven't seen in a while, like Tobias Schlitt.
So to get the latest news, what's going on in PHP world, this will be the place to be in May.

Porting JavaDoc comments to PHP was one of the best things, that ever happened to to PHP4. But like in Java 4, the DocBlocks in PHP evolved from plain documentation to a feature that adds meta information to classes, methods, properties and variables. IDEs, like Zend Studio, use the @var tag to enable type hinting for method return values, which would not possible without the DocBlock, as PHP is a dynamic languages. Furthermore, there are projects like Services_Webservice or SCA, which add custom tags to the docblock to mark a method or class as a service and allow you to generate WSDL and a full-blown webservice server without the need to write additional code.

In Stubbles, we are taking the same approach to add meta-information to our classes but on a more generic level. Through our extended reflection API, we offer the ability to add annotations to classes, properties, methods or functions. Continue reading "My wishlist for PHP 6, pt3: Annotations"

I won't go into detail here, as this topic has been discussed a thousand times on internals. Although prefixing all of your classes works, it still is a PITA. In Stubbles, we are prefixing all our classes with stub, which is fine, as it is a kind of funny prefix, but there are some cases, where this really sucks.

In our implementation of annotations (stay tuned for a tutorial on annotations), every annotation is converted to an object. In our first implementation, the class name had to be the same as the annotation name, but this leads to annotation names that aren't that beautiful to read The XMLSerializer component allows you to use the annotation @XMLTag to specify how an object should be serialized to XML. But the classname XMLTag should not b used as everybody could imagine a future xml extension grabbing the class name. To overcome this drawback, the annotation parser will pre- and postfix the annotation names, so the annotation @XMLTag loads a class called stubXMLTagAnnotation. Namespace support would help us get rid of these little annoyances, as we could import the XMLTag class from the package net.stubbles.xml.annotations. So unless someone comes up for a good reason against namespaces, they will hopefully be part of PHP 6.

BTW: Please spare me the "PHP is not Java" comments, as I already know this.

I was very pleased, that PHP 5 introduced type hints, although they are not available for primitives like string, int, boolean, etc. Still, I'd like to see the object type hint introduced in any future version of PHP that allows me to specify, that a method or function only accepts an object, regardless of the type of the object:
class Processor { public static function processObject(object $obj) { echo get_class($obj) . "\n"; } }
Currently you always have to specify a class or interface name, but I can't see, why this is needed. In Java, this is no problem, as they have a common base class for all of their classes, which is not the case with PHP. So when trying to call this method with an object like this:
class Foo{} Processor::processObject($foo);
you get the following error:

Catchable fatal error: Argument 1 passed to Processor::processObject() must be an instance of object, instance of Foo given, called in test.php on line 14 and defined in test.php on line 6

The reflection extension lets us do a lot of funky stuff without knowing anything about the passed object, so I can't see a reason why this feature should not be implemented. If this already is possible in PHP, please let me know. If not, I hope that Marcus Börger is reading this entry and will implement this for PHP 6 . And yes, I'm well aware, that this might create some problems if anybody has a class named Object, but please don't start another namespace flamewar (although namespace are one of my other wishes for PHP 6).

And while we are talking about it: What about a ressource type hint, that will only accept ressources, that can be processed by functions like fread() and fclose()?

Today you are witnessing the dawn of a new time. The Stubbles developers finally started blogging. Expect to find tutorials, thoughts about new features or just musings about PHP in this blog.

To learn more about Stubbles, either wait for more blog entries or visit the development site.