Stubblog

Those who are familiar with the XP-Framework may be interested to hear that it is possible to load and use the classes of XP natively within Stubbles. Read on for an example how to do that. Continue reading "Loading classes from the XP-Framework"

In an earlier entry I promised that we will explain why we develop Stubbles. Well, there is a short version of it and a long version.

Short version: for us.
Read on for the long version. Continue reading "Why we develop Stubbles"

Terry Chay made some remarks to my last blog entry about a solution for lazy class loading without using __autoload(). Some of his statements seem like I explained my implementation not good enough leading to wrong interpretations. In this blog entry I'll use some of his statements to take a deeper look into my implementation and show that he has drawed some conclusions which I want to disprove.

He writes:

Frank makes his classes that need to be serialized implement an interface (technically, it is subclassed from his base object). This object has a method (not __sleep) that serializes itself into a special object containing this data along with a string containing the class path. This object is included before session_start and reads the full path name to include the class definition just in time.

This approach violates my central tenet of looking for solutions in practices or functions. He closes himself off to built-in functions of __sleep() and __wakeup() because he is no longer serializing the class itself, he’s serializing a stub object.

That is not correct. To show this I will dig into some technical details of my implementation:

class stubSerializedObject implements stubObject { /** * full qualified class name of the serialized class * * @var string */ protected $className; [...] /** * the serialized class data * * @var string */ protected $data; /** * constructor * * @param stubObject $object the stubObject instance to serialize */ public function __construct(stubObject $object) { $this->className = $object->getClassName(); $this->hashCode = $object->hashCode(); $this->data = serialize($object); } [... rest of class ...]

I have marked the important line. It shows that the object itself is serialized which means that one can still use __sleep() and __wakeup() within the class to serialize. Obviously, there is no parallel architecture for serialization and deserialization, its just wrapped.

You can’t use two frameworks, because in this case they would have conflicting ways of deserializing themselves. If you wanted to use a library from PEAR, you’d be forced to put an adapter pattern in front of it just to get the fucker to serialize.

As it should become clear from what I explained above you can still put any other classes you use (maybe those from PEAR) into the session without worrying about how they should be serialized - it just uses the default serialization mechanism.

$session->putValue('stubblesClass', $stubblesClass); $session->putValue('PEAR_Example_Class', $pearExampleClass);

No need to have an adapter. Our session implementation takes care of the correct handling. And no problem if you use another session class from another framework: in this case you just can't make use of the lazy loading, but still put the object into the session as you do with any other one.

More to the point, not storing classpaths with the serialized object is a Good Thing™. Since the session is most-likely stored across servers (via the memcache best practice), storing class paths with the sessions means the directory architecture has to be shared across servers.

Well, not the whole classpath is stored. Our class loader knows where the classes reside. The "class path" is just the path from there to the correct subdirectory containing the file with the class. Therefore the directory structure can be different on another server, it is just required that the directory structure of your source directory is the same, but the path to the source directory can be different on each server. So there is nowhere a hard path, the stored class path is just a relative one.

In case you use the PHP session mechanism the manual has a warning for you:

If you do turn on session.auto_start then you cannot put objects into your sessions since the class definition has to be loaded before starting the session in order to recreate the objects in your session.

This also applies if you use session_start() but did not load all classes that have been put into the session in earlier requests. This can result in problems if you have a very lazy class loading and do not want to use the __autoload() feature. In Stubbles we do not use __autoload() for several reasons, one of them is that we don't want PEARified class names in style of PACKAGE_SUBPACKAGE_ABSTRACTCLASS_CONCRETEIMPLEMENTATION. I simply don't like them, its one of the reasons why I choose SimpleTest over PHPUnit. But when there is no __autoload(), how could lazy loading work?

A decision made earlier was to have a basic interface for all our classes, called stubObject. Every class implements this interface (of course there is a default implementation). The trick is done with an additional class, which represents a serialized state of the concrete class. Every stubObject offers a getSerialized() method which returns a stubSerializedObject. This contains the full qualified classname and a serialized representation of the stubObject. It also features a getUnserialized() method which will load the class if it has not been loaded yet and then unserializes the stubObject .

Because the stubSerializedObject is always loaded in Stubbles our session implementation can now check if a value to store is an instance of stubObject. If it is, it just stores the return value of its getSerialized() method. On a later request, when the value should be retrieved from the session, the session checks if the instance to return is of type stubSerializedObject - if this is the case it returns the return value of its getUnserialized() method which loads the required class if this has not been done yet.

This approach seems to me even better than using __autoload(): it will load the required classes only if they are really used. If they are stored within the session but the current request does not use it the appropriate class will not be loaded. Very lazy, isn't it?