[development] Giving form_alter an $op and calling it more than once.

[Bèr Kessels]

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 at webschuur.com
  http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc
 PGP berkessels at gmx.net
  http://www.webschuur.com/sites/webschuur.com/files/ber_gmx.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20060418/d4fb5728/attachment.pgp