1. I’m noticing a pattern emerge whilst writing the simplified auth code: multiple event listeners which don’t know about each other working on the same object, augmenting and changing it.

    E.G. RememberMeListener looks for an encrypted cookie with a URL (my user ID of choice) in — if it finds one it makes an ActivityStream person object and puts it in request.attributes.user.

    Then, in the same event chain but at a lower priority level, the Contacts module looks in request.attributes.user for a URL. It looks up the URL in my people DB and, if there is anyone, augments request.attributes.user with all the extra info (full name, roles, photo URL, rel value, etc.)

    Then, another listener could run, looking for request.attributes.user with only URL — and look the URL up on identengine.com, caching the response.

    Other example is @-name autolinking, working on a similar basis of: basic transformation (raw data => common data format), then progressive augmentation adding URLs, names and rel values.

    I think this a very powerful and flexible pattern and something I will make a founding principle of Taproot.

  2. Finally decided that symfony Security component is way too complicated for my little , so ditching it — but I’ve learnt a lot from digging through it and my further efforts will try to provide some of the amazing flexibility it gives whilst being more performant and easier to understand #php

  3. I love that now has shiny namespacing and a thriving code sharing community, but I think the heavily hierarchical namespacing practises used by some of the community (e.g. symfony components) are unhealthy.

    They are difficult to memorise, relying on (often slow) IDE autocomplete, and encourage a use statement for each class. That’s pretty much a scoped equivalent of from x import * in python — not a good practise! It’s still namespace pollution, it just takes longer to write.

    I am trying to use a more python–like, package-centred approach with much fewer subnamespaces. The outcome of this should be that you use the package name:

    use BarnabyWalters
osse;

    …and then using all the classes/subnamespaces from that root, e.g: $t = Posse\Helpers::convertHtmlToTwitterFormat($s);

  4. Rolled out usage of the menu element on . I’m looking forward to more browser support for HTML context menus, that will really open up the possibilities for cross-browser extensions