- 2013-09-25: Presenting the history of the Drupal block system at DrupalCon Prague.
- 2013-09-20 to 29: Working on Drupal 8 EntityAPI at the extended code sprints during and around DrupalCon Prague
- 2012-08-19: Working on Drupal 8 EntityAPI at Drupalcon Munich
- 2012-06-15: Working on Drupal 8 EntityAPI at DrupalDevDays Barcelona
- 2012-03-23: Working on the future Drupal Document Oriented Storage at DrupalCon Denver. D8 or later ?
Bets are onLater
- 2009-11-29: mongodb_watchdog module created by dereine, ported to D7 by me in about half an hour, and migrated in a larger MongoDB project by damz before the hour ended. Wow...
So DrupalCon Prague is almost over, and I can now share with you the video of my session about the history of the Drupal block system, from drop.org to Drupal 8, just as recorded on wednesday.
The session page is available on https://prague2013.drupal.org/session/blocks-drop.org-drupal-8-and-beyond where you can also rate it. Please to it over there, or add your comments here: it is very useful for me to see what needs to be adjusted for upcoming presentations. Based on the overall feedback, it seems that:
Just noticed this little gem on a 10Gen course, about the respective names of the CRUD operations in common practice, versus the equivalent operations in SQL and in MongoDB. Links point to Wikipedia for SQL and the relevant MongoDB documentation page for the MongoDB column.
Some of the features in PHP may be surprising. Think for instance of the way PDO is able to create classed results, place the query results into them, and only then invoke the constructor when using
PDO::FETCH_CLASS fetch mode without the additional
PDO::FETCH_PROPS_LATE. Every wished you could do this in userland code ? Turns out this has long been possible, and is even simpler since PHP 5.4.
I was checking a bunch of Behat features left by former developers on a project, and noticed that the Rake rule to run them looked like:
$ behat -c config/behat.yml features
But this looked suspiciously like defaut options. How about running them more simply like just
$ behat ? Alas, this would throw something like:
These last few days, I had noticed a problem with Drush Make and patches: some patches, be they rolled by our team or from elsewhere, would apply without a glitch, but some others, which worked normally according to the test bot on Drupal.org, would fail to apply without any obvious reason.
I had mostly put it out of my list of pressing issues when I really had to use an old version of OpenLayers, 7.x-2.0-alpha2 to be specific, AND apply a patch fixing one of the bugs in that module: behaviors plugin not being located correctly (http://drupal.org/node/1898662 if you want details). So I rolled the patch, tested it locally, the qa.d.o bot applied it and did not report more errors than expected for that old version.... and my Drush Make install refused to apply it.
Here was the relevant excerpt:
projects[domain] = 3.7
projects[domain][patch] = "http://drupal.org/files/domain-foreach_argument-1879502-1.patch"
projects[openlayers] = 2.0-alpha2
projects[openlayers][patch] = "http://drupal.org/files/0001-Fix-the-path-file-declaration-for-behaviors.patch"
The Domain patch applied normally, but the OpenLayers patch would't apply. What could be wrong ?
Continuing this exploration of logging solutions used in various projects, let's look at logging in Kohana 3.
While Monolog and log4php share a mostly common logging model of a frontal Logger object instantiated as many times as needed to supply different logging channels, in which log events are Processed/Filtered then written out by Handlers/Writers, Kohana builds upon a simpler model, which can be summarized by three patterns:
- Singleton: there is only one instance of the Kohana
Log_Writerinstances are attached (and detached) to(/from) the logger instance and handle events they are interested in based on their own configuration. Much like a Drupal hook, all writer instances receive each
- Delegation: the
write()to trigger the buffered writing, but does not implement it itself, but delegates to the
Log_Writerobjects to perform it. Buffered logging control is a
Logproperty, not a
It is based on the famous log4j package from the Java world, and from uses of this package I have seen on customer sites, I feel that it carries a lot of useless baggage, and is - in my opinion - significantly less of a good match than Monolog for Drupal 8.
Monolog vs log4php : equivalences
There is some degree of equivalence between the Monolog and log4php components:
|Log an event||Logger||Logger||Very similar|
|Store an event||Handler||Appender||both can be chained, group, control bubbling (Monolog) / filtering (log4php)|
|Format an event representation||Formatter||Layout||log4php layouts can format a group of events, Monolog formatters format an individual event|
|Massage event data||Processor||Renderer||Not so similar. Monolog processors will often add extra data, while log4php Renderers are typically used to format non-string events as strings.|
I've been discussing Monolog in Drupal events (DrupalCamp Lyon, DevDays Barcelona) as a possible alternative to the legacy Drupal
watchdog() service for quite some time, but never took the time to explain it in writing, and the feature freeze date is looming ahead, so since I'm taking part in th Gent code sprint, and code has been starting to take shape
here is an overview of the Monolog classes.
The diagram below is a simplified version of the Monolog architecture. It includes all classes and interfaces, but only the most significant methods, no constants, and none of the non-bundled classes and interfaces upon which some of the builtins depend.
If you have been wondering about the general organization of Field API in D8 and did not take time to work yched's existing D8 Field API sandbox, here is a simplified and cleaned-up version of the currently envisioned class and interface set.
Over the last few days, I finally decided to revisit the old OSInet PHP library, to dust it off somehow, and convert the class-based parts to PSR0 and the whole to what seems to be liable to become PSR1 at some point.
This library contains a zoo of function helping with PHP-GTK development, and three packages with their demo application:
- Class Grapher
- Build a graph of inheritance and interface implementations on a directory (and subdirectories) of PHP code
- This package uses the Drupal Grammar Paser to parse code, and includes a Drush 5 plugin for easy use within a Drupal site, but can also be used to parse non-Drupal code, as long as the Grammar Parser - which does not depend on Drupal either - is installed in the include path.
- It is a more complete version of the Drupal-only Class Grapher sandbox on drupal.org.
- In the current version, graphs are generated using GraphViz. An extension to a client-side visualization tool like the Infovis toolkit should come someday. Suggestions for other client-side libraries welcome (please comment!).
- Open Document Calc reader
- This package provides a few classes and methods to extract the content of OpenDocument (LibreOffice, OpenOffice.org, ...) spreadsheets.
- Finite State Machine
- This package is used to build applications designed around a finite state machine, and is mostly intended for use in PHP-GTK applications, to provide asynchronous processing.
- The demo application uses the PHP FTP extension to expose its asynchronous notifications in a PHP-GTK UI