Two newposts on the Symfony blog talk about improvements to the framework's plugin system (as found in recent releases).
A week after the release of the new plugin system, a lot of activity has taken place. More than 30 plugins were created, and 51 new releases were published on 27 different plugins. Based on the feedback I have received from the community, I have made some tweaks to the system.
These tweaks include a newly designed homepage, the inclusion of RSS feeds and a special URL to view the older wiki documentation for some plugins.
The second post describes more enhancements based on other feedback (on the previous post). Updates based on this information include an new "overview" field to describe the plugin, a download of the Markdown syntax to make the documentation conversion easier and a "stric mode" validation if you upload a PEAR package.
A little while back, Alan Knowleswondered something that I'm sure has crosses the mind of every PHP developer out there, especially when they came across a particularly bad chunk of code - some people should need to apply for a license before releasing their PHP code out into the wild.
Unlike most of the reviews you get, I was specifically looking at code quality [of the CMSs]. not fuzzy does it look nice!
He looks at a whole list of them including: Tanslucis, Siteman, Pivot, jaf-cms, Guppy, Doop and CutePHP. Unfortunately, most of the news is bad - between badly structured code and mixes of HTML and PHP, there was almost nothing good in any of them.
On the Stubbles blog, Frank Kleine has pointed out a proposal from Stefan Marr to include functionality for traits in PHP.
As a language construct within PHP it would be very easy to do the same, but easier to learn and to use. Beside some keyword issues (the RFC uses "use" as keyword, but this will of course conflict with namespaces) I'm wondering what this will have an impact on reflection - the RFC stays unclear about this.
A trait is a free-floating chink of functionality that, instead of being confined to a class (or file) that has to be called on to use it, exists where the developer can use it from anywhere at any time. This helps solve some of the issues with single inheritance in PHP.
The latest version of the CodeIgniter framework has officially been released - version 1.6:
EllisLab is proud to announce the release of CodeIgniter 1.6, our open source web application framework. The release marks a new turn in the development of the framework, and has received considerable attention from both EllisLab developers and the community.
There's lots of new features in this new release including a Database Forge class, improvements to their Active Record implementation, an extendable Model class, and the addition of extendable Helpers.
Ed Finkler has pointed out a handy resource for those trying to cope with using the UTF-8 support included in several of PHP's functions - this page on the Web Application Component Toolkit wiki.
This page is intended as a reference for functionality PHP provides which can either help with handling UTF-8 or should be regarded as a risk when used in conjunction with UTF-8 encoded strings. Further information can be found on the Internationalization (I18N) and Character Sets / Character Encoding Issues pages.
It talks about the "dangerous" functionality PHP has (issues that the language has in current functions) when using things like the PCRE extension, the string extension, the array methods, handling variables, the XML extensions (DOM and SAX), image manipulation, and URL parsing functionality.
In this post from Padraic Brady, he compares some of the tools that are available to Ruby developers to some of their counterparts (if they exist) in PHP.
Anyways, here's the pitch. I've been using Ruby for a year now and my pet peeves with PHP started getting a bit too much to comfortably endure. [...] I don't like developing web applications with Ruby, or that thing Rails. Whatever it is. It's a framework, right? So I'm on a splurge of writing PHP tools for the same things in cahoots with folk like Travis Swicegood.
Tools he mentions include Autotest, Mutation testing, Mocha, Rspec, Heckle and some of their PHP counterparts like parts in PHPUnit and the DomDocument functionality.
There is something fundamentally brash, brazen even, to releasing a class named DateTime. [...] I'm going to bump my way through learning how to use this new DateTime lib, bringing all my preconceptions about how it should work. The odds of this being interesting to you is probably nil unless you're in one or two very small cliques, feel free to read on, or browse away.
The article looks at quite a bit of the functionality in the extension - everything from the simple formatting of dates to more complex date object manipulation. A definite read for anyone looking to harness the power of this new functionality.
Mike Lively is happy about one thing - that late static binding (definition) has been committed and will be included with PHP 5.3. Unfortunately, he has a downside too:
The good news is late static binding has been introduced into head and looks like it will be merged into 5.3 before it is released. The horrible news is I really don't think the patch went as far as it needs to.
He talks about the original intention of the functionality (flexible inheritance for static methods/properties/constants) and how it was implemented, but with one small issue - that "static will ALWAYS return the 'resolved' name of the class used to call the current function". He illustrates with a code example showing an extended class returning a static property.
He also mentions two suggestions to help fix this issue:
setting the behavior of parent:: such that it forwards the calling class through the next function call.
introducing another scope [...] using a new keyword so parent:: could remain the same
David Goodwin, a developer on the Propel project has posted about a new feature included in the latest PHP version, the DateTime functionality, and how they put it to use in Propel.
One of the relatively new features in PHP 5.2, is the DateTime class/functions. It has a few useful functions (date_parse, date_date_set, date_time_set etc) which make dealing with dates and times easier (date_parse provides some useful error info too).
He also mentions the ability of the functionality to handles dates before 1970 or after 2038, a common problem with PHP's native date functionality. He illustrates how it's useful by describing the change they made in Propel store DateTime objects instead of the integer timestamps like before.
One more good news for you, YAML-users. I've implemented emitter functionality in php-binding of syck library. It is quite straight-forward, no fancy stuff for now, but it should work.
Supported datatypes include associative arrays, strings, integers, floats, booleans and nulls. He includes an example of the code in action (dumping out the information for an associative array). You can get this latest update from the subversion source on his site.
