Saturday, March 31. 2007
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"
Saturday, March 24. 2007
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:
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:
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"
Wednesday, March 21. 2007
Wednesday, March 21. 2007
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.
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.
That is not correct. To show this I will dig into some technical details of my implementation:
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.
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.
Friday, March 16. 2007
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?
Thursday, March 15. 2007
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.
Thursday, March 1. 2007
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:
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.
« previous page (Page 1 of 1, totaling 7 entries) next page »