more.zites.net

Some months ago I gave git a first try for developing some stacked core patches. I quickly get used to it and to its nice features (german). Luckily its SVN integration is really nice and simple to use so GIT is even a fine replacement for the usual SVN client. Unfortunately for CVS things are much worse.. :( Poor cvs!

First tries..

I decided to don't go back to CVS for maintaining drupal modules. First I tried using the public GIT mirror of the whole drupal CVS from the French drupal community, however I quickly noted that it was broken for the rules module, so I tried to set up my on mirror. I started using Sam Boyer's scripts, however I had some misc small troubles with them, but more important those scripts copy the whole drupal CVS - but I didn't like to waste ~6 gigs of disk space and the time to sync all the unneeded stuff. So I ended writing my own script based on the instructions in the drupal handbook for maintaining a module with git and Sam's script. After some weeks going back and forth I finally ended up with something useful, so here are my experiences:

What is it about?

Currently I've set the script up to export the drupal CVS of some of my modules to GIT - its automatically pushing to my github account, which is quite convenient. It syncs only the really needed modules using rsync - which is an important step as its greatly speeding up cvsps when exporting from CVS. The nice thing is that it doesn't overwrite any changes not yet in CVS, so I can use the same git repository on github to develop new stuff and export to CVS later on.

With drupal 7 the concept of an entity gets introduced in drupal, thus nodes, comments, users, terms - all these are drupal's entities. Most important the also new field API is able to support any entity! So how will this affect the drupal landscape?

I've started with crell's results when benchmarking magic.

Preliminary Warning:
"If you're afraid of classes and objects in PHP, run away now." - jpetso.

Update: For simplicity the API has been changed so that all faces are incorporated, thus modules have to care about naming collisions theirself. Also in the meantime file inclusions support has been added.

While figuring out a object oriented design for the rules engine I recognized the need for a possibility to allow modules extend objects in various places. Thus I developed a generic concept which does just that: Allowing modules to extend objects. I called the concept "Extendable Object Faces", which basically implements the Facade pattern in a modular way.

So let's have a closer look at that. A module that wants to extend an object may only do so on top of a defined interface, preventing uncontrolled growing objects. Thus one can write some code, define an interface for it and attach it to potential any extendable object out there. Then other modules have an easy way to test whether some object has a functionality in place by checking for the availability of a certain interface.
To use that functionality the caller has to use the right "Face" of the object - corresponding to a certain interface. This approach using different "Object Faces" make sure there can't be conflicting method names, so modules don't need to prefix their methods with the module's name which would result in ugly and not readable code.

I've already implemented an initial version of the Extendable Object Faces API. As of now you can:

• Extend an object by providing an Extender Class
• Extend an object simply by some functions, each implementing a method
• Override any dynamically added method by providing functions or an Extender Class

So apart from "allowing modules to extend an object", this also allows one to:

• Easily lazy load huge parts of an objects implementation, invisible for the caller.
• Allow modules to dynamically alter an implementation by using overriding.

Hence such an Extended Object can also serve as a clean abstraction for module provided callbacks!

Enough talk, let's show how it works:

This code provides the class for the Extendable Object and already defines an interface, which modules may implement. So let's extend it with an Extender Class.

That's it. Now you can use the face!

As you see, one has to use the face to be able to use the added method - so potential name collisions are avoided. However the Extendable Class can define so called incorporated faces, which are built in the Extendable Object as soon as a module provides an implementation:

So you can use it that way, once extended:

You can find more examples in the simpletests I've written. Also checkout the benchmarks I've run.

So what's missing? Basically the implementation is complete and working fine. Though feedback and suggestions are very welcome! However currently the code doesn't deal with including code where the implementation can reside (lazy loading), though for drupal 7 that is already solved by the code registry (just add one call to drupal_function_exists()). For drupal 6 I think about adding the possibility to specify include files per added interface.

Dreaming...

If we would have an object oriented "Data API" in drupal core, this could serve as a way to let modules extend those objects. So instead of writing node-centric code code could would be written in a generic way - attachable to potentially each of those data objects (users, comments, terms). Having such generic code would allow us to finally end the "Everything should be a node" debate. Apart from that this would help us to easily lazy load big chunks of code, just exploiting the code registry!

Finally, after over 1 year of development the rules module has reached the 1.0 version! You can download it from the project page.

Reactive rules?
Reactive rules (or ECA-rules) are rules triggered upon a given event. This allows one to conditionally fire actions based on arbitrary events. As modules can provide further conditions, actions and events this enables site builders to automate a lot of things using reactive rules! As of now a lot of popular drupal modules provide already rules integration: CCK, Organic Groups, Token, Flag, Content Profile, Content Access, ViewsBulkOperations and many more.

Features?
The modules comes with a bunch of useful features, e.g. a flexible input evaluation system that allows to use token replacements or even PHP evaluation in your rules. To ease the management of rules the module supports tagging of rules as well as Import/Export. Often used behaviour can be put into Rule-Sets and is easily invoked by provided actions. Not enough, the execution of those Rule-Sets can be scheduled easily with help of the provided action, thus providing a powerful scheduling system, which allows you to schedule arbitrary tasks!

It's finally grown-up?
Rules is already stable for quite a time, however I didn't consider it to be complete. During the last months I added missing important features, fixed bugs and translation issues and completed the documentation! While there was quite a bunch of useful developer documentation for a while, now there is also a complete hook reference in the doxygen format.

So it's grown up, but it's not (yet) perfect. So what comes next?

I've just released the first release candidate for rules 1.0. Read more at groups.drupal.org!

A lot of people run drupal with lighttpd, a light and fast webserver, which uses FastCGI to support PHP. As lighttpd doesn't read .htaccess files, some extra config is required to get drupal's clean urls working right.

I'm doing so already for a while now, finally I found the best way to do clean urls with lighttpd. I started with some url-rewriting regexes, which isn't ideal as there are problems with some special paths or dots. I've improved the regexes a bit, but still there were problems.

Another common way is to use a lua-script. The big advantage of this script is that one can do the url rewriting based on the condition whether there is a file for the requested path - so no regex magic is required. Thus there also no problems with dots.
The disadvantage of that approach is it's inflexibility. When you want to install multiple drupal instances in several different sub directories or use a script to generate settings for all your drupal instances, it's odd that the lua variant needs one script per drupal prefix, because you have to set the prefix in the lua script!

Finally I found a way to work around this inflexibility. First off I looked into passing the prefix variable into the lua script, but I had no luck with that. So I decided to go for another approach: I wrote a simple wrapper script, that creates the needed lua script with the right prefix set on the fly. So when lighttpd parses your configuration it calls the wrapper script, which makes sure there is a lua script in place and returns the suiting configuration for your drupal installation.

Ok, enough talk. Let's see how it works.

For the second exercise of my Information Retrieval course at the university I had to do implement a relevance feedback system - so I thought: Why not build it upon drupal's search?

So that's what I did. The result is a working proof of concept module, which you can find in my sandbox and test at the demo site.

The system has two operation modes: One that uses "implicit feedback" and one that let's the user give "explicit feedback". The implicit feedback mode just tracks which search results the user has viewed, takes these results as relevant to generate an optimised search query and shows the improved results to the user.

The explicit system works the same way, but provides some UI for users to mark results as relevant and non-relevant, as you can see on the screenshot:

You can test the system at the demo site, which runs in explicit feedback mode. Once you have provided three positive results as feedback the system makes use of the Rocchio algorithm to generate an optimised search query and redirects you to the improved search results.

I've just committed a major update to the pageroute module. I've reorganized the page types and created a new one: the node management type.

The node management page allows one to add/edit/delete nodes from a configurable content type. It shows a themeable list of already created nodes and allows editing and deleting if the user has access.

The node management page type was the last important piece missing for nodeprofiles: A userfriendly way to create several nodes of the same type.

I've separated the modules into own projects, as they are not only for nodeprofiles useful.

Now there are the following drupal projects:

Node Profile
Node Family
Views Fusion
Pageroute