The other day on IRC #drupal-contribute I overheard a brief conversation regarding rules - it wasn't heated, just some fretting about rules - one of the commerce guys (@rfay) rightly stressed that rules needs to be understood as a language in itself. That in itself makes people - especially those comfortable coding PHP - very wary. Rightly so: drupal has shied away from abstractions like templating engines[1] and the thought of implementing something like "DrupalScript" makes me shudder to the core. But why install module bloat to point-click-and-configure something that you could do w/ one hook and 4 lines of code?[2]
My take on rules - echoing Johan Falk's "summary" of rules on the DrupalEasy Podcast ("Rules makes things happen on your website") - is a slightly larger one:
Rules is to Drupal what Drupal is to your website!
Like most CMS's Drupal has lowered the barrier for editors (end-users) to put content online. Rules lowers the barrier of adding (business) logic to your Drupal site for sitebuilders (non-coders), allowing them to move beyond modelling content and "making things happen on your website" in a structured way[3]. Drupal IMHO will never be a framework for "elite"-coders, instead Drupal's rather unique value proposition is another:
You don't have be a coder to get 80% of the way - you can have "sitebuilders" that need technical as well as architectural thinking and understanding (but not a CS-degree); more importantly: they can get 80% done independently without making the remaining 20% impossible for a Drupal-savvy coder to add.
Whilst it's easy to scoff at point-and-click configuration, it makes sense also from a developer's perspective. When new to Drupal i balked at using Views, knowing SQL well I feared I would get stuck in corner cases [3]. But now i write Views integrations instead because I know that my sitebuilding colleages can grok views. This also applies to rules: without the rules.module I probably would have never started the wf_field.module ... not because a "state machine" is particularly hard to code, but because I would have had to introduce yet another way of handling actions, triggers, arguments, that goes miles beyond simple module_invoke_all() and drupal core's actions/trigger - in short: rules. And I would have had to add a UI for sitebuilders as well - API-only doesn't cut it.[4]
It's good to be vary of abstractions, but sometimes these abstractions make a lot sense, stand the test of time and provide considerable efficiency gains! Whilst Rules still has to stand the test of time (compared to e.g. Views), the momentum and technical skill of the people behind Rules and Drupal Commerce (heavily rules-driven), makes it seem quite a good bet!
[1] I know it's possible to use template engines (e.g. smarty) - but, really, nobody does that :)
[2] Some pointed out that complex conditions (OR, AND) can be difficult to model with that hook-approach; some "easy gains" like vbo integration (NEW! SHINY!) are also apparent ...
[3] GROUP and OR clauses in views2?
[4] Just like no-api doesn't ...
Add new comment