Hi Guy, I'm not quite sure what your question is, I guess you're asking for recommendations on how to proceed? I'd guess that a general, database driven action might be part of the solution you're looking for?
In any case, we are also actively working on a dynamically configurable wizard type of solution for an intranet system. Basically, I've been looking at the problem as one of architecting a web based user interface to handle dynamic work flow. As such, I've been focusing on using work flow descriptions, which I think would map to your navigation rules. The reason I point this out is that you might find enough maturity in the workflow world for XML specifications of workflow rules to suite your needs. (You may even find workflow IDEs that can spit out usable XML, but that's likely not a issue given your description.) We are not yet looking at using Cocoon 2.1 since it is not yet stable. Also for us, I'd like to keep all business logic processing purely server side. I've had a couple other messages here and on the user list about the architecture we are looking at, which is basically to use XSLT to parse XML rules and spit out the next screen. The dev thread http://marc.theaimsgroup.com/?t=103338042200004&r=1&w=2 contains some of that discussion if you're interested (though this issue is not explicitly discussed in that thread). Your comment about state machines caught my eye and leads to the following speculation: with a rule based system, state transitions are encoded in the rule specifications; it should be possible to write a rule parser and a rule specification that encodes any state machine but not vice versa (since rules can be ill defined and, as you note, cyclic). (As such, you can likely prove that, in general a sitemap can't be mapped to a state machine, but that's the opposite of your issue.) I see state machines as useful for parsing of well defined protocols, but not, as a general approach for parsing business rules. One needs a word other than state when discussing the "state" of rule based systems; "context" seems to roughly meet our needs, though on these lists it may have other connotations (from the Servlet/HTTP world) that imply certain interface implementations for some people. One of my main goals (and it seems yours) is to not code business logic in the sitemap. I'm also not completely comfortable with actions since I don't want to encode our business logic directly in Java (or code some complex rules engine in Java). Our approach so far is to instead have business logic managed through parsing of the context via running an XSLT over an XML description of the current context and an XML description of the rules for the current context. Note that the context information can be drawn from the request, the session and a database. Likely, rules are only drawn from the database. You end up using XSTL to determine how the interaction of the current context modifies the rules base and vice versa (eg. similar to black boards and scratch pads in expert systems). The end result is a context pruned, filtered and enhanced (almost sounds like the beginning of a Cocoon slogan) for the next presentation round... We're not yet at a point where we can implement this, so I'm basically looking for comments and ideas on how to handle this whole issue. Your problem description matches up well with what we are up against (though eventually our "wizards" will have to work with expert systems based rule resolves and less precision than you describe). As such, I'd be interested if you've explored other alternatives (architectural or implementations) and/or if you're comfortable that C 2.1 will be stable enough for your development in the timeframes you need? -----Original Message----- From: Guy Boertje [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 09, 2002 5:46 AM To: cocoon-dev Subject: XMLForm complexity example/question Hi All, I am a new Cocoon user - just got 2.1 from CVS. Been looking at 2.0.3 in Tomcat and Jetty on NT4. I have looked at the 2.1 wizard example and it is v elegant - congrats to the cocoon team. I have also read through the list archive wrt XMLForms and Flow etc. I have previously co-developed an ASP based application for a global finance house. It is a request wizard - DB driven, with 4/5 data collection steps. Form content is derived from a set of db based item trees - each tree being a request. The user selects which request they want and that begins a traversal of the tree. Each step's data is cached in the db as a part request. Users can complete the request at another time. Fatal limitations were found when we wanted to use the supplied data to decide which path to follow for the next step. Cocoon and XMLForm seems unlimited in this regard. I am working on an alternative. These are (some of) the requirements. 1) The forms need to be editable by request system admin. (Certainly new requests need to be created) 2) Some steps could be shared across requests. 3) Requests are a list of possible forms. 4) Requests are completed by navigating along a path of forms. 5) Navigation rules describe the transition conditions needed to move to another form. 6) Navigation rules can use supplied data from any step. 7) First fired rule wins. 8) Request navigation rules need to editable by request system admin. (Create new or fix routing errors) 9) If the user navigates back and forth changing paths, at the finish, data collected along the _final_ path are preserved and any other data is dropped. Cocoon 2.1 has 1) and 2) covered but navigation rules are in an Action so they are not user editable. With the correct form model 6) can be achieved in an Action. The Navigation rules describe a directed graph not necessarily acyclic, the real world constrains the cycle - say to collect a repeated data looping through some steps. I realise that there could be work -arounds e.g. to put repeated form elements on the same HTML page and usability issues with too many repeated steps or too long a path. My understanding of the sitemap concept is that it is a kind of state machine transition map except the from-state and the next-state are disregarded in favour of an any-state to next-state transitions. I have designed UI as state machines and they can get quite complex. If one regards a wizard as a kind of state machine with a begin point and some end point then using a sitemap for the transition flow seems a corruption of the beauty of the sitemap. I regard the Action solution to the wizard navigation as acceptable. Only that I would like the transition logic to be indirect and not in the WizardAction class code. Once again, congratulations to the whole team. Regards, Guy Boertje --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
