more.zites.netAbout using git to maintain a drupal module...
Posted January 6th, 2010 by fagoSome 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.
Are entities drupal's new nodes?
Posted November 6th, 2009 by fagoRules session @Drupalcon Paris
Posted October 4th, 2009 by fagoI'm on vacation...
Benchmarking Extendable Object Faces
Posted July 6th, 2009 by fagoIntroducing the concept of Extendable Object Faces (API)
Posted July 6th, 2009 by fagoPreliminary 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:
<?php
interface FacesTestInterface {
function isWorking($prefix);
}
/**
* Extendable Class
*/
class FacesTestElement extends FacesExtendable {
//Your code here..
}
?>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.
<?php
/**
* Extender Class
*/
class FacesTestExtender extends FacesExtender implements FacesTestInterface {
function isWorking($prefix) {
return $prefix . $this->object->name;
}
}
?>That's it. Now you can use the face!
<?php
$element = new FacesTestElement();
$element->name = 'test';
$element->extendByClass(array('FacesTestInterface'), 'FacesTestExtender');
// Now use it.
print $element->face('FacesTestInterface')->isWorking('Name:');
// This prints "Name:test".
?>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:
<?php
/**
* New extendable Class
*/
class FacesTestElement extends FacesExtendable {
public function getIncorporatedFaces() {
return array('FacesTestInterface');
}
}
?>So you can use it that way, once extended:
<?php
print $element->isWorking('Name:');
?>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!
Reactive rules for drupal have grown-up!
Posted May 18th, 2009 by fagoFinally, 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?
Rules 1.0-rc1 is out!
Posted April 20th, 2009 by fagoFlag module 6.x-1.0 shipping with rules integration!
Posted March 18th, 2009 by fagoFinally the flag module got released - a really useful module and known as the successor of the previous "Views bookmarks" module. The project page says:
Flag is a flexible flagging system that is completely customizable by the administrator. Using this module, the site administrator can provide any number of flags for nodes, comments, or users. Some possibilities include bookmarks, marking important, friends, or flag as offensive. With extensive views integration, you can create custom lists of popular content or keep tabs on important content.
But even better the 1.0 (and 1.1) release is shipping with extensive rules integration. So once you have installed both modules you can create flags and use rules to add some behaviour to them, e.g. you can react once a flag is "flagged" or "unflagged" and send mail to the content node's author, unpublish it, change the content's access settings - or whatever you have actions and conditions for!
Then the module also provides actions for flagging or unflagging flags, checking the flag count in case of global flags and even to "Trim flags", which allows you to restrict the number of flagged items. This way you could even create simple queues. Of course there also conditions to check whether a flag is flagged and again in case of a global flag you can check the flagging count. Amazing!
Also the flag module comes with a bunch of useful settings, so you can configure the flag to have a confirmation form or to just work with an AJAX link. Together with the powerful rules integration one could implement a lot of useful stuff - want a custom link with custom permissions to publish a content node? Just use a flag and an appropriate rule!
Bringing rules to the next level!
Posted March 5th, 2009 by fago