[development] Giving form_alter an $op and calling it more than
ber at webschuur.com
Tue Apr 18 09:51:50 UTC 2006
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
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.
PGP ber at webschuur.com
PGP berkessels at gmx.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20060418/d4fb5728/attachment.pgp
More information about the development