Topics

programming

php drupal scheme scheming macros design patterns da la

design

design css

random thoughts

scribbles

alter ego

other me 'em that link us my space me linked in

Collections

Programmable web
PHP design patterns

Similar things

  • Wizardy, druidy, wiz
  • Multi-page forms using form api
  • Going mad talking about relations
  • Relations and their domain structures
  • Relation modules
  • Relations battle plan
  • Once again relations, or the need to focus on smaller parts of the big picture. A rant.
  • Relations Battle Plan II and first results
  • A pause for thought and some cut backs
  • standalone dependency.inc

Home » blogs » vlado's blog

Drupal, computer science, random bits

Submitted by vlado on Wed, 2007-06-13 08:50.drupal | programming | shorts

There are quite a few interesting computer science artefacts in Drupal. I'm going to try to highlight a few of them. Sorry, this is unfinished, and might not be finished ever, but I'm just trying to capture a snapshot of confused meandering thoughts.

Very late, dynamic binding

Late binding came to popular life with the advent of object oriented languages. Essentially it means binding of values, for example functions, to names at object creation, as opposed to compile or link time. In drupal, this can happen at any time, more even, it is algorithmic - that is you can change at runtime what is to be executed at a specific control point. The hook system is one of the ways to do it.

Algorithmic type derivatives

A related subject - type extensions in Drupal. First of a types - that is types of objects drupal deals with, the base php types, user, node, taxonomy, term, file, drupal arrays,....

Type derivatives are algorithic, context sensitive, have a generally rewriting as opposed to extending. Let's take a look at the richest drupal type - node.

Node has a default structure. A trimmed version - node id, title, body. From these the only actually required is the node id, but it can be ommited, since it is an automatic, system attribute of a node object.

You could implement derived node types, all they need to do is to obey the node protocol - required and maybe optional node hooks. Alternatively you can alias a node type. For example look at page and story in drupal core v5.

There is a 'type alteration' mechanism, hook nodeapi. It allows you to dynamically modify a node object at different times of its life - load, insert, delete, view, .... Generally it is used as a type extension mechanism, but can be used to actually perform any kind of transform of the type object. Not type safe, but generally any transform will do, as long as you preserve the node protocol. The transform is non-deterministic, since you can't guarantee the order of execution.

Annotated arrays transformation

A variation on the theme is the structured arrays, as advocated by form api, now spreading to areas removed from form processing. They are a kind of an annotated graph, processed by a transformer. In the presense of standard processing elements and allowing extensible callbacks (annotations), this structure starts resembling an AST of an aspect oriented language.

The structured arrays, allow you to add a lot of flexibility to how to structure your object abstractions in drupal. For example look at the drupal form api. You can conditionally alter the structure of the form array, change it's functionality and how it should be presented. Attach different validation functions, introduce new form element types, ....

The combination of these tools leads to a fairly unpredictable (unless you accept the danger of non-determinism, and code around it, juet remember - it is not checked), but quite interesting and fairly elegant framework for creating websites. Collaborative or others.

vlado's blog | add new comment
Home » blogs » vlado's blog

dikini.net

spreading confusion by accident since 1970