Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 80711 invoked from network); 13 Mar 2004 19:37:22 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 13 Mar 2004 19:37:22 -0000 Received: (qmail 2702 invoked by uid 500); 13 Mar 2004 19:37:08 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 2672 invoked by uid 500); 13 Mar 2004 19:37:08 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 2652 invoked from network); 13 Mar 2004 19:37:08 -0000 Received: from unknown (HELO mail.s-und-n.de) (212.8.217.2) by daedalus.apache.org with SMTP; 13 Mar 2004 19:37:08 -0000 Received: from notes.sundn.de (ntsrv5.sundn.de [10.10.2.10]) by mail.s-und-n.de (postfix) with ESMTP id 1E03019F56C for ; Sat, 13 Mar 2004 20:37:12 +0100 (CET) Received: from s-und-n.de ([10.10.20.145]) by notes.sundn.de (Lotus Domino Release 6.5) with ESMTP id 2004031320313201-106404 ; Sat, 13 Mar 2004 20:31:32 +0100 Message-ID: <40536440.3040805@s-und-n.de> Date: Sat, 13 Mar 2004 20:42:56 +0100 From: Guido Casper User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: Responses to workflow experiences References: In-Reply-To: X-MIMETrack: Itemize by SMTP Server on PBSN1/Systeme und Netzwerke(Release 6.5|September 26, 2003) at 13.03.2004 20:31:32, Serialize by Router on PBSN1/Systeme und Netzwerke(Release 6.5|September 26, 2003) at 13.03.2004 20:31:33, Serialize complete at 13.03.2004 20:31:33 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Johan Stuyts wrote: > A summary of my interpretation of the workflow thread is available on > the wiki (http://wiki.cocoondev.org/Wiki.jsp?page=Workflow). Please > verify my findings and I'm sorry if I misinterpreted something. > Thanks a lot for your effort, Johan. I don't want this workflow thing being stalled and somehow feel like being my turn. So my suggestion is to settle on the interface I proposed earlier: -setState(doc, requestedState, user, optionalObject) -getState(doc) -getAllowedActions(docURI, user) I think this leaves enough space for different implementations (and is not carved in stone anyway). "doc" might be an implementation of WorkflowObject with (at least) get/setState(), getType() and getURI() methods and "user" might be an implementation of WorkflowUser with getUsername() and getRole() (allowing the details of getting this information being abstracted away from the workflow engine (if desired)). Note that in most cases (like myself's :-) this might require not much more than having the objects you might already have implement WorkflowUser/WorkflowObject. I can offer to rework my approach a little (making it more generic) and put it into scratchpad. Be aware that it will however require at least 3 (to make up a meaningful sample) non-reusable (although tiny) Java components. Although being simple (which might be ideal for discussing and settling on an interface anyway) I believe the state pattern provides various extension points (like for nested states, XML descriptions or user-defined workflows), which might provoke further ideas where my mind left. Just a few examples. Looking at my earlier config like this:

If you need multiple workflows that simply might become

... easily allowing the config being externalized in separate files and allowing objects to dynamically change the workflow. If you prefer more reusable Java code and your custom logic being interpreted rather than compiled that might be made into something like:

switch (requestedState) { case "reviewed": allow = true; break; case "published": if (userRole == "editor") { allow = true; break; } default: allow = false; }

if (userRole == "editor") { allow = true;} else {allow = false}

How much easier can it get? Note that I don't want to throw another technology into the mix (and there are certainly people on this list being able to integrate Rhino equally easily), just want to show how flexible the state pattern is. And basically that's a major point, it gives you a very flexible approach while allowing you to continue working with what you are already familiar with. WDYT? Guido -- Guido Casper ------------------------------------------------- S&N AG, Competence Center Open Source Tel.: +49-5251-1581-87 Klingenderstr. 5 mailto:gcasper@s-und-n.de D-33100 Paderborn http://www.s-und-n.de -------------------------------------------------