Op dinsdag 18 april 2006 11:14, schreef drupal:
$ops are messages, hooks are a kind of a message as well. Implementing a fixed, well defined set of messages called on every single hook call will make it a performance nightmare.
I do NOT want to turn this into an OOP flamewar, so if you want to say anything against of for OOP please open a new thread. That said, one thing i was impressed by, is that modules in a Ruby on Rails environment (railfrog, or typo) are extremely small. A typical module weights only four or five lines of code. The biggest reason is its OOP implementation. Messages sent to objects are, indeed, a very very powerfull tool. Because you need not implement all sorts of checks and you need not know anything about the object. All you need to know is the part you want to modify/add to/remove etc and do that. The good part is that automagically everything (users, categories, posts, comments), sort-of, becomes a node, with a sort-of nodeapi and a sort-of node-lifecycle and even a sort-of modular access control. However, when I brainstormed about how such power could be implemented into a Drupal hook system, I came to Valdo's conclusion: having an object oriented system built as hook system into Drupal, on top of PHP is simply never going to cut it, performance being the biggest issue. My only solution for this was caching and registration (see below).
A far better solution, from a flexiibility point of view, is to be able to schedule for invoke a new hook. For example, if something wants to run before load, it can schedule in init "my_post_init_hook". This way it is guaranteed to run after init and before load. It houldn't be a lot of work, and addresses, at least partially, the flexible page workflow ramblings. The dowenside of this is that it will make debugging code harder. But that is quite hard anyway, and needs to be addressed.
Whether we go for a set of predefined $ops or in some post-during-pre hook system does not really matter. The fact that a module registers hooks does matter. For performance that is. This, however, is a standalone project, and has little to do with the initial thought of this thread, to make form_alter more flexible. (Though it is a requirement if we go for a huge set of 'messages'/$ops and hooks). Back to the point: What if we re-do the lifecycle of a node ins the form system? That would mean you have form_alter($op) with: $op = load (collecting the form, change) $op = view (theming, changing the behaviour, reordering and so) $op = insert (data is inserted) $op = validate (valdation) At least, this gives consistency wit hthat part we all (should) know: nodeapi. Bèr -- PGP ber@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc PGP berkessels@gmx.net http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc