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: Dries Status: patch (code needs review) 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. Dries 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