I was writing about new features in the upcoming PHP version (5.4, 6.0?) before. Today's topic reads like this in the NEWS file:
- Added array dereferencing support. (Felipe)
Now you might wonder what this typical short entry means. when doing OO-style PHP you might make use of a sntax feature which one might call "object dereferencing" which looks like this:
<?php
class Foo {
public function bar() { }
}
function func() {
return new Foo();
}
func()->bar();
?>
So one can chain method calls or property access. Now for a long time people requested the same thing for array offset access. This was often rejected due to uncertainties about memory issues, as we don't like memory leaks. But after proper evaluation Felipe committed the patch which allows you to do things like
<?php
function foo() {
return array(1, 2, 3);
}
echo foo()[2]; // prints 3
?>
Of course this also works with closures:
<?php
$func = function() { return array('a', 'b', 'c'); };
echo $func()[0]; // prints a
?>
And even though the following example is stupid I might accept this feature might make one of the few places where it is ok to use references in PHP:
<?php
$data = array('me', 'myself', 'you');
function &get_data() {
return $GLOBALS['data'];
}
get_data()[2] = 'I'; // $data will now contain 'me', 'myself' and 'I'
?>
Wonderful, isn't it? If you want to test it please take a look at the recent snapshots for PHP trunk and send us your feedback! Please mind that all features in PHP trunk may or may not appear in the next major PHP release.
I finally sat down and started work on a sandboxed DOM API. Originally I was just going to develop a new framework because the DOM is messy but instead I decided it would be cool to have a safe simulated DOM instead and build a framework on top of that.
It isn’t complete yet and there’s still a lot of work to do but it’s working pretty good. I still need to run some tests on it and try to break it but I don’t have time at the moment as I need to do other stuff.
One of the problems making a DOM API is that IE doesn’t have setter support even in IE8 it doesn’t allow you to define setters on normal objects. Because I spend most of my time hacking stuff it was a fun challenge to make IE support setters on DOM objects and keep my sandboxed whitelists.
It’s quite complicated and quite ugly in parts but it works and I think it’s the only way to support legacy browsers like IE7.
I have to test for the various setter support including defineSetter, Object.defineProperty and revert to the legacy onpropertychange. Object.defineProperty works fine in IE8 when using a DOM object but I encountered problems when I needed to assign to a sandboxed normal object. Here it gets ugly, I had to create a DOM object for any styles used by a node, this way both Object.defineProperty and onpropertychange allow me to monitor any assignments to the fake style object.
var styles = document.createElement('span');
node.$style$ = styles;
Object.defineProperty(node.$style$, '$'+cssProp+'$', {});
document.getElementById('styleObjs').appendChild(styles);
node.$style$ = styles;
node.$style$.onpropertychange = function(){}
As you can see with the code sample above I have to append the fake style DOM object for onpropertychange otherwise it won’t be called on assignments.
You can see this working by using the following test code:-
document.getElementById('x').style.color='#ccc';
So I proxy off all these functions and make the root node any html object, I use CSSReg and htmlReg to sandbox each modification to a property. Finally where it got complicated was supporting events, currently I only support “onclick” as I’m still testing but what happens is because the code is already sandboxed I don’t need to perform a rewrite so I pass this to JSReg as it’s already been converted, I supply the “this” object as the html element this allows the triggered event to call “this” as the current element.
That’s it! I’ve donated the code to OWASP and it will be free to use in your projects, any help testing or suggestions are most welcome, enjoy the demo!
We are currently working on an app that uses a number of technologies, including PHP, Python, and MongoDB. Recently, a need arose to use sequential identifiers for users, similar to an auto_increment column in MySQL.
If you've used MongoDB, you might be familiar with the default behavior of using a UUID as the primary key. This is convenient, especially if you partition your database across servers, because you don't have to coordinate the primary key in any way. If you use sequential identifiers (as I demonstrate in this post), you can use multiple servers and interleave identifiers by advancing each server's sequence by the total number of servers. (For example, with two servers, advance each sequence by two, so one server generates even identifiers, and the other generates odd.)
I'd rather not discuss the advantages and disadvantages of either approach, because it's exactly this debate that makes it very difficult to find any useful information on using sequential identifiers with MongoDB. Instead, I'm just going to explain how I did it, and hope this is helpful to someone. :-)
First, create a sequence collection that you can use to determine the next identifier in the sequence. The following creates a collection called seq that has a single sequence in it (for users), but you can add as many as you need:
db.seq.insert({"_id":"users", "seq":new NumberLong(1)});
If you assign seq to 1 instead of new NumberLong(1), it will be interpreted as a float due to a JavaScript quirk.
Before adding a new user, you need to increment the sequence by one and fetch the next identifier. Fortunately, the findandmodify() command provides an atomic way to do this. Using the MongoDB shell, the command would look something like this:
db.seq.findAndModify({query: {"_id":"users"},update: {$inc: {"seq":1}},new: true});
Because I'm using Lithium, I added a method for fetching the next identifier to my User model:
<?phpnamespace app\models;class User extends \lithium\data\Model {static public function seq() {$seq = static::_connection()->connection->command(array('findandmodify' => 'seq','query' => array('_id' => 'users'),'update' => array('$inc' => array('seq' => 1)),'new' => TRUE));return $seq
Truncated by Planet PHP, read more at the original (another 2980 bytes)
Earlier this week, I spent most of a day tracing through code in search of the source of a bug that was causing part of our application to fail in strange ways.
In the back end, we have models that connect to CouchDB. These models implement the Iterator pattern to allow easy traversal of a record’s keys.
When I wrote the code to implement Iterator several months
ago, I dutifully checked the PHP
Manual and adapted the reference example that I found there:
<?php
class Record implements Iterator
{
// (partial class, showing the iterator implementation only)
public $_data = array();
public function rewind()
{
reset($this->_data);
}
public function current()
{
return current($this->_data);
}
public function key()
{
return key($this->_data);
}
public function next()
{
return next($this->_data);
}
public function valid()
{
return (current($this->_data) !== false);
}
}
Little did I realize that this implementation is very broken. I’ll explain why, below.
Over the past few years, I’ve implemented many iterators in
this way, using PHP’s implicit array manipulation functions
(reset(), current(), key(),
next()). These functions are very convenient because PHP
arrays are so powerful — arrays in PHP work like ordered hash tables in other
languages.
PHP’s implicit management of an array’s iteration index
(the value that is incremented by next() and
referenced by key()) is indeed convenient, but the convenience
can sometimes be offset by its very implicitness — the value is hidden from
you, the PHP programmer.
In PHP, generic array iteration (without the implicit iterator) isn’t actually as simple as it sounds. Remember that arrays aren’t arrays in the traditional sense, but ordered hash tables. Consider this:
$data = array('zero','one','two','three');
for ($i=0; $i<count($data); $i++) {
// yeah, don't calculate count() on every iteration
echo "{$data[$i]}\n";
}
Output:
zero
one
two
three
This first example is easy to iterate — the array contains sequential, numeric, zero-based keys. It gets more complicated when using non-sequential, and non-numeric keys:
$data = array(
'apple',
'cow' => 'moo',
'pig' => 'oink',
'orange'
);
for ($i=0; $i<count($data); $i++) {
echo "{$data[$i]}\n";
}
Output:
apple
orange
Notice: Undefined offset: 2 in - on line 10
Notice: Undefined offset: 3 in - on line 10
I could use foreach, but because a numeric loop illustrates the point more clearly, here’s how I might implement the above code so that it works:
$data = array(
'apple',
'cow' => 'moo',
'pig' => 'oink',
'orange'
);
$k = array_keys($data);
for ($i=0; $i<count($data); $i++) {
echo "{$data[$k[$i]]}\n";
}
Output:
apple
moo
oink
orange
This brings us back to the Iterator implementation. Why
isn’t the code above correct? Take a closer look at this:
public function valid()
{
return (current($this->_data) !== false);
}
A value of false in the array is indistinguishable from a
false value returned by current(). Using the
above implementation with the following array would cause it to bail after
orange (and subsequently might cause you to waste a day
tracking down the cause):
array(
'apple',
'orange',
false,
'banana',
);
On Tuesday night, I
updated the manual
to use an
improved Iterator implementation.
It’s probably a bit slower (so you
can use the internal-indexing implementation if you’re sure your arrays
will never contain false), but my implementation is more
robust.
<?php
/**
* A mixed-key iterator implementation
*
* Note: these array_keys() calls are slow. The array keys could be cached
* as long as the cache value is invalidated when $_data is changed.
*/
class It implements Iterator
{
public $_data = array();
protected $_index = 0;
public function rewind()
{
$this->_index = 0;
}
public function current()
{
$k = array_keys($thisTruncated by Planet PHP, read more at the original (another 765 bytes)
Just a heads up for all of those in the Dallas/Ft. Worth area – there’s a great one-day event coming up this Friday (July 31st) blending PHP, .NET, Java, new media, Joomla and WordPress into one packed day of sessions – Dallas TechFest 2010 at the University of Texas at Dallas.
I’ll be giving a session called “Building a Web Service API” from 10:30 – 11:45am in the PHP track. Here’s a summary of the session:
When is a web application more than just a web application? Hook up an API and you’ll see! I’ll walk you through the basics of what an API is and the concepts behind it as well as key pieces of technology you can use to create both the client and server. There’s a focus on PHP but other languages and tools will be touched on as well.
There’s still time to register for the event – tickets can be purchased for an early bird price (ending today) of $50 or $60 at the door. You can see the full list of sessions here.
As I mentioned in my previous post, my beer recipes are now online.
I've had several people ask me how this is done, so I think a post is in order.
While it's entirely possible to brew beer at home without any fancy gadgets, there are several tools I use (such as my refractometer) that make the process easier, more controlled, or both. Brewing software is one of the few instruments that I'm not sure I'd want to brew without. I use a Mac, primarily, so Beer Alchemy (BA) is the obvious choice for recipe formulation, calculation, and logging.
BA has its own html export mechanism for recipes, and I used this for quite a long time, but I was never really satisfied with the results. The markup was hard to style, contained a lot of clutter (occasionally useful, but often redundant information such as style parameters), and simply didn't fit well with the rest of my site.

You can also export from BA in PDF (not suitable for web publishing), ProMash's binary recipe format (a pain to convert, although there do seem to be some tools to help with this), BeerXML (normally the most accessible, but in my opinion, a poorly-designed XML format), or in BA's native .bar ("Beer Alchemy Recipe") format, which is what I chose.

The bar format contains a property list, similar to those found throughout Apple systems. Property lists are either binary or XML (but the XML is very difficult to work with using traditional tools because of the way it employs element peering instead of a hierarchy to manage relationships). Luckily, I found a project called CFPropertyList that allows for easy plist handling in PHP. (I even contributed a minor change to this project, a while ago.)
Once you've run the .bar file's contents through CFPropertyList, layout is very simple. Here's most of the code I use to generate my recipes:
<?php
$beerPath = __DIR__ . '/../resources/beer/';
$recipes = apc_fetch('seancoates_recipes');
$fromCache = true;
if ($recipes === false) {
$fromCache = false;
foreach (new DirectoryIterator($beerPath) as $f) {
if ($f->isDot()) {
continue;
}
if (substr($f->getFilename(), -4) != '.bar') {
continue;
}
$cfpl = new CFPropertyList($beerPath . '/' . $f->getFilename());
$recipe = $cfpl->toArray();
$title = $recipe['RecipeTitle'];
$recipes[self::slugify($title)] = array(
'title' => $title,
'content' => $recipe,
);
}
asort($recipes);
if ($recipes) {
apc_store('seancoates_recipes', $recipes, 3600); // 1h
}
}
In addition to displaying the recipe's data, I also wanted to show the approximate (calculated) beer colour. Normally, beer recipes declare their colour in "SRM" (Standard Reference Method). There's no obvious, simple, and direct way to get from SRM (which is a number from 0 to 40—and higher, but above the mid 30s is basically "black") to an html colour.
I found a few tables online, but I wasn't terribly happy with any of them, and keeping a dictionary for lookups was big and ugly. I like the way Beer Alchemy previews its colours, and since it has html output, I emailed the author to see if he'd be willing to share his algorithm. Steve from Kent Place Software graciously sent me an excerpt from his Objective C code, and I translated it to PHP. This might be useful for someone, and since Steve also granted me permission to publish my version of the algorithm, here it is:
<?php
/**
* Calculate html colour from SRM
* Thanks to Steve from Kent Place Software (Beer Alchemy)
*
* @param float $srm the SRM value to turn into html
* @return string html colour (without leading #)
*/
public function srm2html($srm)
{
if ($srm <= 0.1) { // It's water
$r = 197;
$g = 232;
$b = 248;
} elseif ($srm <= 2) {
$r = 250;
$g = 250;
$b = 60;
} elseif ($srm <= 12) {
$r = (250 - (6 * ($srTruncated by Planet PHP, read more at the original (another 3023 bytes)
To bring CMS editing to the next level, the IKS project is working on a semantic html5 editor. This week we had a hackathon in Helsinki focusing on implementing our ideas with the Aloha Editor. In addition to enjoying the hot summer weather here, we accomplished quite a bit and in the end were able to present the whole pipeline of:

The hackathon participants included developers from Nemein, Gentics, Infigo, Salzburg Research and the German Research Center for Artificial Intelligence. Some screenshots:

Editing content with Aloha in Midgard

Annotating persons with the Aloha RDFa plugin

RDFa annotation created with the semantic editor
Additional semantic information suggested by FISE
All the relevant code can be found from GitHub (see also the FISE Midgard integration).
Bookmark and Share this page