XMLForm complexity example/question

[Guy Boertje <gu...@rockbay.co.uk>]

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

Use Case

For a fictional NT account request.  A series of questions are asked with
the principle of least amount of rights
awarded in mind.  Without offering the user a choice of Admin, Power User,
Backup Operator etc.- questions
should allow a IT Security person to award sufficient rights to the NT
account(s) or perhaps automation can
create the account.  Here follows a lengthy definition of the request
wizard.

PAGE start:
  identify themself (requestor)
  identify who the account is for (request-for)
  select one: new user | existing user
  select one: domain user | machine user
  select one: plain user | privileged user
  button: next
  if next & start/new-user, show page account-new
    PAGE account-new:
      select one: department
      tick: user role is known
      button: back
      button: next
      if back, show page start
      if next & account-new/user-role-known-ticked,
              show page account-role
        PAGE account-role allows user to:
          select one: user role
              (subset by dept e.g. salesperson, marketing manager)
          button: back
          button: next
          if back, show page account-new
          if next & start/domain-user, show page domain-selection
          if next & start/machine-user, show page machine-selection
      if next & !account-new/user-role-known-ticked,
              show page account-role-questions
        PAGE account-role-questions:
          select one: line manager (subset by dept)
          select one: co-worker (subset by dept)
          button: back
          button: next
          if back show page account-new
          if next & start/domain-user,
              show page domain-selection
          if next & start/machine-user,
              show page machine-selection
  if next & start/domain-user, show page domain-selection
  if next & start/machine-user, show page machine-selection
    PAGE domain-selection:
      select one: domain
      button: back
      button: next
      if back & account-role/user-role, show page account-role
      if back & account-role-questions/line-manager,
          show page account-role-questions
      if back & account-role-questions/co-worker,
          show page account-role-questions
      if next & plain-domain-user-questions/more,
          show page domain-user-select
      if next & start/new-user & start/plain-user,
          show page plain-domain-user-questions
      if next & start/new-user & start/privileged-user,
          show page privileged-domain-user-questions
      if next & start/existing-user, show page domain-user-select
    PAGE machine-selection allows user to:
      select one: machine
      button: back
      button: next
      if back & account-role/user-role, show page account-role
      if back & account-role-questions/line-manager,
          show page account-role-questions
      if back & account-role-questions/co-worker,
          show page account-role-questions
      if next & start/new-user & start/plain-user,
          show page plain-machine-user-questions
      if next & start/new-user & start/privileged-user,
          show page privileged-machine-user-questions
      if next & start/existing-user, show page machine-user-select
  PAGE domain-user-select:
    select one: domain-user
    button: back
    button: next
    if back, show page domain-selection
    if next & plain-domain-user-questions/more,
        show page plain-domain-user-questions
    if next & start/plain-user,
        show page plain-domain-user-questions
    if next & start/privileged-user,
        show page privileged-domain-user-questions
  PAGE machine-user-select:
    select one: machine-user
    button: back
    button: next
    if back, show page machine-selection
    if next & start/plain-user,
        show page plain-machine-user-questions
    if next & start/privileged-user,
        show page privileged-machine-user-questions
  PAGE plain-domain-user-questions
    tick: create email account if not exists
    enter: cost centre
    (other domain account relevant questions)
    tick: reuse answers (for multiple user entry)
    button: back
    button: more users
    button: more users new domain
    button: next
    if back, show page domain-user-select
    if more users, show page domain-user-select (save answers)
    if more users new domain,
        show page domain selection (save answers)
        ('save answers' business logic will test the reuse answers
        and retrieve the answers from the previous user in the bean)
    if next, show page request confirmation
(other user questions pages follow the same format)
  PAGE request confirmation
    (show read only tabular view of request)
    button: back
    button: finish
    (as all paths terminate here the back button has all the
    conditional logic to take the user back to the previous page)
    if finish, redirect to request home



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org