Subscribe: Stubblog
Added By: Feedage Forager Feedage Grade B rated
Language: English
annotations  code  directory  file  logic  method  new  release  released  stubbles  variant  vfsstream released  vfsstream 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Stubblog


Less slogan, more code.


vfsStream 1.1.0 released


With the release of vfsstream 1.1.0 a whole range of new features is introduced. First and foremost is support for new features which became possible with PHP 5.4, namely that 5.4 enables support for touch(), chown(), chgrp() and chmod() on stream wrappers. vfsStream 1.1.0 now supports these functions, which means they can be applied to vfsStream urls. This allows to test functions and methods which change file permissions or ownership.

Another new feature that came along with PHP 5.4 is support for truncating stream wrapper streams via ftruncate(). Of course, vfsStream now supports this as well.

Despite support for the new PHP 5.4 features vfsStream 1.1.0 can still be used with PHP 5.3, but of course without the features requiring PHP 5.4.

Last but not least vfsStream 1.1.0 introduces a new quota feature. This allows to limit the available space in the virtual file system and allows to simulate how your code behaves in case you run out of disk space. For more details check the documentation.

As there was no release announcement for 1.0.0, here is what changed with 1.0.0: vfsStream was changed to make use of namespaces, which means support for PHP 5.2 was dropped. All vfsStream classes now reside in org\bovigo\vfs. (Yeah, it is. Maybe I'm spoiled by Java here. (image) ) Besides that, the release contains some bug fixes. See changelog for a complete list of changes.

Additionally, since 1.0.0 vfsStream is no longer available via PEAR, but via Composer. You can get releases via Packagist.

As the old PEAR server on ceased to exist I made a 0.12.0 release available at This one is not supported, for bc purposes only and only if you still require a version running with PHP 5.2. Otherwise, it is recommended to upgrade to the 1.x series using Composer.

vfsStream 0.11.1 released


Today we released vfsStream 0.11.1 which contains an important bugfix for usages of mkdir(). Until 0.11.1 calls to mkdir() with vfsStream URLs replace already existing directories or files, instead of returning false and trigger a warning. This has been fixed with 0.11.1. Thanks to Julien Fontanet for reporting the issue.

As always you can get the new release via our pear channel.

vfsStream 0.11.0 released


Some minutes ago vfsStream 0.11.0 was released with several bug fixes and new features. Unfortunately this introduces a BC break to the vfsStream::create() method introduced with 0.10.0. While in 0.10.0 it completely replaced the directory structure this is not the case any more. It now only adds the given structure to an existing structure, either to the directory given with the second parameter, or to the root directory without removing any other childs of the root directory. If you want to replace the whole directory tree you can use the vfsStream::setup() method which now has a third parameter. See create complex directory structures documentation for code examples.

Another new feature is the possibility to import a file system structure from disc into vfsStream. This way you can emulate an existing file structure in vfsStream without having to recreate it from scratch. See copy from file system documentation for more details.

Additionally, three bugs were fixed: unlink() does not remove non-empty directory any more, vfsStreamDirectory::hasChild() now doesn't give false positives for nested paths (patch provided by Andrew Coulton), and opening a file for reading only doesn't update the modification time any more (initial patch provided by Ludovic Chabant).

Thanks to all contributors and issue reporters for their help to improve vfsStream.

As always you can get the new release via our pear channel.

vfsStream 0.10.1 released


Today vfsStream 0.10.1 has been released, containing two bug fixes. The first was a problem with the vfsStream::create() functionality introduced with 0.10.0, where using numeric directories failed because of implicit type conversions (in PHP) and explicit type checks (in vfsStream). Thanks to Mathieu Kooiman for finding this issue and providing a patch.

The other fix is a mix of a documentation and type hinting fix: now you can only use directories as root instance - before it was allowed to add files as vfsStream root with with vfsStreamWrapper::setRoot(), however this failed latest when trying to access other files with a directory name. Starting with 0.10.1 you can not add files as root any more, and this was also used to change the return type documentation so you can get better auto completion when retrieving a directory object with vfsStreamWrapper::getRoot(). Thanks to Dmitry Kabanov for reporting this issue.

As always you can get the new release via our pear channel.

vfsStream 0.10.0 released


Not even ten days after the release of vfsStream 0.9.0 today the fresh version 0.10.0 hits the streets, containing various improvements to make your life with vfsStream much easier. Especially when you want to create more than just two or three files it's really noisy to create the directory structure. To ease this vfsStream now provides a vfsStream::create() method which accepts an array and builds the directory structure from it. See create complex directory structures for more details.

Another improvement is that vfsStream now supports flock() meaning that you can call flock() with a vfsStream file url and afterwards check the file instance whether the lock was set correctly. Another requested feature was the possibility to print out directory structures, but I had the idea of providing even more possibilities on what you could do when inspecting the directory structure. For a more detailed view on what this new feature provides check the wiki page about Visitors.

Also this release introduces a BC break. As announced with 0.9.0 the then deprecated method vfsStreamContent::setFilemtime() was removed now - please use fsStreamContent::lastModified() instead.

In order to ensure better compatibility between PHP 5.2 and 5.3 calling support for stream_set_blocking(), stream_set_timeout() and stream_set_write_buffer() on 5.3 was added. However calls with these functions always return false and do not have any influence on vfsStream, which is rather because concrete usage scenarios are a bit unclear at the moment. If you have any ideas or feature requests on how vfsStream should treat such calls feel free to add your comments on issue #15.

You can get the new release via our pear channel.

vfsStream 0.9.0 released


Today the new 0.9.0 release of vfsStream was shipped to our PEAR channel. This release ships with a new feature that allows (unit) test scenarios which make use of file access time and file attribute modification time. While there is no restriction on usage of the file access time, support for file attribute modification time is still quite limited due to the fact that PHP's stream wrapper do not support changing file attributes via chmod(), chown() and chgrp(). However, this might change with PHP 5.4 but this is some month away from today.

Another issue fixed (well, kind of) is the problem that calls to stream_select() with vfsStream-URLs did not cause problems with PHP 5.2 but with 5.3 - this release makes sure that vfsStream behaves the same under both versions. Unfortunately it continues that stream_select() does not work with vfsStream-URLs as the only possible implementation of the stream_cast() method was to return false. Actually it is expected to return the underlying resource, but there is no such resource in vfsStream, and returning resources pointing to data:// scheme URLs does not work either.

More changes are the deprecation of the vfsStreamAbstractContent::setFilemtime() method in favor of vfsStreamAbstractContent::lastModified(), which means the aforementioned is scheduled to be removed with the next minor release (most likely 0.10.0). You should change your code accordingly if you make use of this method. Last but not least there was a bug that not all given URLs were resolved correctly, leading to the problem that in the second parameter of rename() and in mkdir() no dots could be used, which is fixed now.

You can get the new release via our pear channel.

By the way, did you notice that development of vfsStream has moved to Github?

Stubbles 1.6.0 released


Today we released Stubbles 1.6.0, which is another major step of abandoning our XJConf for PHP dependency. The variant manager configuration can still be done using XML, but we don't use XJConf any more, but an own parser which is much simpler and uses less resources. It is not as powerful as XJConf, but powerful enough for all features required for variant configuration, and still being able to extend this configuration with user-defined tags. So the 1.6 series will also be the last one where XJConf is bundled. In the 1.7 series XJConf will not be part of the release any more, and all XJConf related code will be moved into a separate project.

Another improvement is the fact that there is no need any more for specific annotation classes. If no specific annotation class is present the new stubGenericAnnotation class will be used. This is sufficient for most use cases, and Stubbles will only use the new generic class internally.

One last improvement is the possibility to use injection providers for constant values as well. Until now it was only possible to set a concrete value for a constant, but starting with 1.6.0 it can now be bound to an injection provider which may calculate the value at runtime or use other classes to retrieve the actual value.

See the full changelog for all details of changes for this release.

Stubbles 1.6.0 RC1


To start with the Stubbles 1.6 series the first release candidate 1.6.0 RC1 is now available:

Please test it thoroughly with your applications and report any bugs into our Trac installation.

For a list of changes please see the changelog.

If no obstacles rise up the scheduled release for 1.6.0 is March 8th.

Stubbles 1.5.1 released


Today we released Stubbles 1.5.1. This is a bugfix release, fixing one bug inside the XML/XSL view engine that prohibited usage of the common page path for including xsl stylesheets from the common project. You can get the release from our downloads page.

Stubbles for XP: an experiment


Last Friday I went to farewell party of a friend of mine, and on this evening I talked with Alex Kiesel who is one of the XP framework developers about various things, injection support within the XP framework amongst them. As you might or might not know, both Stubbles and XP are similar in some areas, mostly because the developers share a common mindset about what a framework should provide and how things should be done. This got me into thinking about the injection topic more deeply, as I was convinced that a port of the Stubbles IoC package should be feasible without any large efforts, providing the same features as in Stubbles.

Over the weekend I stopped thinking about it and fired my IDE to just code it. And as it turned out, the port was almost a no-brainer. I got everything to work very quickly, and was able to port the test cases as well, gathering 33 running tests.

Unfortunately there is one feature which the XP port can not provide, which is named injection for more than one argument on constructors or setter methods. This means if you need to have a named injection you require a single setter method for each named injection. This is due to the fact that XP does not provide annotations for method parameters, so the @Named annotation can only be applied to methods and therefore is used for all arguments of such an annotated method.

While the idea of "Stubbles for XP" has been thought more than once in the past and this little experiment shows it is possible, it would still be a long way to go, and the IoC package is just a very small part of it. However, to have room for more experiments of such a kind I named the experiment "Stubbles for XP". If you are interested in the source just have a look at the subversion repository. If you just want to play around with it you might simply download the stubbles-for-xp-0.1.1.xar file.

However, there is one more caveat until now: I had to patch lang.XPClass because I found no suitable way to call its newInstance() method with a list of arguments, and I don't wanted to use call_user_func_array(). So if you decide to play with it you need to apply a patch. The patch was developed against 5.8.1-dev, but also successfully tested with 5.7.13, same applies to the port itself.

Update: thanks to a hint from Timm it is now possible to use the 0.1.1 release against XP without applying the aforementioned patch.

On annotations and logic


When we started Stubbles and implemented the annotation feature we drafted them as first class citizens within the code, being classes containing their data and also with the possibility to contain logic. While this was quite a good idea in the beginning and it offered a lot of possibilities and freedom to implement features which revolve around the usage of annotations, I came to the opinion that it's not such a good idea at all. The most simplest reason for this is the idea that annotations are markup. They mark (or, to keep the notion, annotate) code as being special or to be treated in some special kind of way, depending on the scenario where the code is used in, with scenario meaning something like creating the object graph for the application, serializing data to XML or into a database, or populating objects with values from a given source. What is common to all these scenarios is that you have some kind of logic which treats arbitrary objects where both logic and treated objects don't know anything about each other. The only thing which ties them together and tells the logic how to to treat the object are annotations, they give hints how the logic should perform in regard to the object. From a design point of view this makes it clear why annotations should not contain logic. If annotations contain parts of such logic, it becomes splitted and possibly cluttered throughout different classes: in the main class of the logic, possibly in any subclasses which you can and should not prevent if required, and in annotations. It's basically a violation of the single responsibility principle. The single responsibility of an annotation is to mark up code, not to execute logic which is not related to the markup itself. A second reason is that logic in annotations does not promote code reusage. It's bound to the specific annotation, and there is no way to reuse it in another scenario without annotations. Probably the logic is useful in another way, were informations about how to treat an object does not come from annotations - than it is really helpful to not have any part of the logic in annotations. Or the other way round, it's even harder to reuse other code within the logic constrained in annotations as you are limited to what you can insert into the scope in which annotations are read and created. What does this mean for Stubbles? In the past days I've revisited all framework code which makes use of annotations, and changed it in a way that all parts of the logic are in specialised classes which are part of the logic. This allowed to get two improvements: for the filter annotations api this means that annotated filters can now be created in exactly the same manner as filters which are explicitly requested, via the same source and configuration. The other improvement is within the XML serializer, it lead to much clearer and simpler code then we had before. The improvements are part of the next milestone release 1.6.0 (no release date yet). I'm also questioning the requirement of the possibility to have different annotation classes. However, I did not came to a final conclusion on this issue yet, but in regard to the language and environment I think it might be enough to have a single annotation class which simply works as data container, maybe even to force logic out of annotations this way. On the other hand, having a separate class might be a good way to provide validation of the annotation values and to prevent wrong usage of the annotation. One might also consider the point of being able to restrict annotations to certain places, e.g. to restrict the usage of annotations just to methods or properties. But is this really required, e.g. does it provide a useful feature? This has to be answered with no if viewed from the logic, as the logic si[...]

Stubbles 1.5.0 released


A new year, a new minor release. With Stubbles 1.5.0 we continue to adhere to our release early, release often approach. The release contains further improvements on our IoC feature, as well as API improvements for various classes in the ipo package. A major change however is that we discontinue to provide several different versions of the release. Until now, all releases contained various packaged versions of the framework classes inside the lib directory. This has changed, starting with 1.5.0 we only provide the stubbles.php file. For a full list of changes please see the changelog.

But we don't stop at this point. Work on the 1.6.0 release has already started and will see tweaks to how we use annotations. But more on this in a separate blog post coming soon.

Stubbles 1.5.0 RC1


To start with the Stubbles 1.5 series the first release candidate 1.5.0 RC1 is now available:

Please test it thoroughly with your applications and report any bugs into our Trac installation.

For a list of changes please see the changelog.

If no obstacles rise up the scheduled release for 1.5.0 is January 19th.

Stubbles 1.3.4 and 1.4.4 released


On the last day of 2010 the probably last releases of the Stubbles 1.3 and 1.4 series are now available: releases 1.3.4 and 1.4.4. Both contain bug fixes for handling of variant cookies so that detecting a variant from cookies now works properly.

You can get the latest release from our downloads page.

Stubbles 1.3.3 and 1.4.3 released


Today we released Stubbles 1.3.3 and 1.4.3. The releases include improvements for the XML/XSL view engine. One of them is the removal of a required xsl-imports.ini configuration file if only the default imports should be used - as the engine would not work without the default imports properly the configuration file needs only to be used if there are additional user-defined XSL stylesheets to be imported.

The other improvements revolve around the variant support. Until now the cookie which stores the variant was not re-evaluated when the variant configuration changed. This is different now, as the name of the variant configuration is now stored in another cookie. If the name of the variant configuration changes the variant cookie will not be used to determine the correct variant for the user. This means the user will get a fresh new variant, even if he has the name of an older variant in his cookie and the old variant is still configured, which is especially useful when starting a new variant test.

In order to ease selecting the correct variant when working in development or stage mode, especially when it comes to random variants, the stage assistant now contains a variant selector which can be used to change the current variant of the website.

You can get the latest release from our downloads page.