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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
