[drupal-devel] [feature] insane state machine patch

[dikini]

Issue status update for 
http://drupal.org/node/28113
Post a follow up: 
http://drupal.org/project/comments/add/28113

 Project:      Drupal
 Version:      cvs
 Component:    base system
 Category:     feature requests
 Priority:     normal
 Assigned to:  dikini
 Reported by:  dikini
 Updated by:   dikini
 Status:       patch (code needs review)

"I don't see how this makes it easier to insert callbacks/phases unless
you split functions in small steps to begin with.

"
Yes, it's true. But drupal hooks are callbacks. At the moment they are
called in quite a few places, but since their calls are embedded in
php, adding a callback in the middle of the chain becomes not trivial. 


A good example is placing form elements using nodeapi, there three
'main' areas, which is fine, but sometimes insufficient.


The current patch and file don't do that - simply not to complicate
this particular code. I can post an example rework of node later.


"What are 'flexible page workflows' to begin with?

"
I hope not to start a flame war. It seems workflow is an overloaded
word. What I mean by that buzzwordy phrase is to be able add or modify
the order in which the different callbacks or hooks are called, when
rendering a page, for example. This is an attempt to streamline it.
Nothing really fancy, although the words might suggest it.




dikini



Previous comments:
------------------------------------------------------------------------

Wed, 03 Aug 2005 14:59:11 +0000 : dikini

Attachment: http://drupal.org/files/issues/insane_state_machine.patch (9.8 KB)

This is a patch to introduce a simple (or insane if yo like) state
machine. 


Why? After some irc discussions it came out that a lot of people would
like flexible page workflow. This patch and the include file to follow
offer a starting point to that. It doesn't change any of the standard
apis, or the current workflow. Just enables the possibility of it.


What changes? Introduce a new file - includes/machine.inc. It the most
important part of it is the drupal_run() function. It implements the
said machine. I've moved drupal_bootstrap and some relatives to this
file, since it is easier to read the code when drupal_run and
drupal_bootstrap are together. I've changed index.php, xml_rpc.php,
update.php and cron.php to reflect the changes.


I could've submitted a far bigger patch, but decided that the least
intrusive, incremental approach is better. This is probably the reason,
 you would ask
Q: Why do we want this thing?
A: An approach like this opens several avenues to do more with drupal
hooks. 


Let's take for example the node workflow. The execution of the
different hooks is strictly ordered and immutable. There is no way for
a module to insert a phase somewhere in that sequence. If, for example
node is reworked to use this or similar approach the default node
workflow will become mutable. This will offer a lot interesting
opportunities, while not changing the current node behaviour and apis
from its clients point of view.


A second example I can see is easier implementation of the install and
update system, since it will be able to hook into and extend drupal
before the database is available, or into any other phase of the
bootstrap process. The current code doesn't forbid branching.


OK, this is long enough as it is, so I stop here




------------------------------------------------------------------------

Wed, 03 Aug 2005 15:00:08 +0000 : dikini

Attachment: http://drupal.org/files/issues/machine.inc (3.21 KB)

and the include file




------------------------------------------------------------------------

Wed, 03 Aug 2005 15:19:44 +0000 : Dries

And how exactly would 'flexible page workflows' benefit from this?  What
are 'flexible page workflows' to begin with?  


I don't see how this makes it easier to insert callbacks/phases unless
you split functions in small steps to begin with.