On Mon, Jan 22, 2001 at 07:55:28PM +0100, Dieter Maurer wrote:
Oliver Vecernik writes:
I'm designing an application gathering data with forms. Navigation
should be done with Prev and Next buttons. As long as I'm not leaving
the form data should be entered, processed and the *same* or another
form should be displayed, depending on input of the user.
So far I'm able to gather data, store them in a database, but can
anybody give me a clue or point me to some docs how to control which
form should be displayed next? It should depend on users input of let's
say a text field.
Look for the "RESPONSE.redirect" method.
Dieter
Dieter, as usual, gave a good succinct answer. But in this case, I
think that the problem is in the way the question is framed, and not
the answer.
I am going to give a completely different answer, based on what I think
the original questioner really needed, it will be a bit long.
I am assuming that the application lays in a folder called MyApplication.
I am going to use a particular coding style that I call "going nowhere",
it is actually a state machine. I am going to use hidden variables to
hold state, you can also use cookies, database connections or other
mechanisms.
index_html is just a chain of if statements that encode what to
display next.
For example:
dtml-if "not REQUEST.has_key('current_state')"
dtml-var entry_form
dtml-elif "current_state=='process_entry' and action=='Next'"
dtml-var next_form
dtml-elif "current_state=='next_entry' and action=='Prev'"
dtml-var entry_form
.
.
.
/dtml-if
entry_form looks like
form action=. method=post
input type=hidden name=current_state value="process_entry"
input type=text size=15 name=my_variable
input type=submit name=action value="Next"
/form
(This is where the "going nowhere" comes from. All forms use
. as the action, so the browser never goes to another folder.)
Now, it should be easy to see how to modify index_html to handle
displaying a different form depending on the previous input.
Just put in in one of the tests.
-
To elaborate this just a bit, I also typically do an error_entry__form
that looks like:
form action=. method=post
font color = reddtml-var error_message/font
input type=hidden name=current_state value="process_entry"
input type=text size=15 name=my_variable value="dtml-var my_variable"
input type=submit name=action value="Next"
/form
and change my index_html to look like:
dtml-if "not REQUEST.has_key('current_state')"
dtml-var entry_form
dtml-elif "current_state=='process_entry' and action=='Next'"
dtml-var handle_process_entry_next
dtml-elif "current_state=='next_entry' and action=='Prev'"
dtml-var handle_process_entry_prev
.
.
.
/dtml-if
Then
handle_process_entry_next looks like:
dtml-call "REQUEST.set('error_message', '')"
dtml-call canonify_process_entry_next_data
dtml-call check_process_next_errors
dtml-if "error_message != ''"
dtml-var error_entry_form
dtml-else
dtml-var next_form
/dtml-if
(canonify_... does approriate things like stripping, converting to a particular
case, etc.; check_... enforces data consistency conditions.)
This is not an original idea. I saw it when I was pretty green, myself, and
really did not understand its attraction and power. Here are what I now see
as the benefits. All of the application is kept in a single folder. The
index_html is boilerplate, essentially a single long if-statement. The
canonify_ and check_ methods are likely to be very small also, and can be
implemented in any language. The forms are essentially pure HTML, and can
be kept very simple (OK, the error_form has a smattering of very simple
DTML to reset the last value of the user's input). Error handling is natural
and easy to do. You do not have to redirect.
Redirection destroys your REQUEST, forcing you to do other things to hold
information.
The cost, only that an application's folder gets to be somewhat large.
Jim Penny
___
Zope maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope-dev )
___
Zope maillist - [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope
** No cross posts or HTML encoding! **
(Related lists -
http://lists.zope.org/mailman/listinfo/zope-announce
http://lists.zope.org/mailman/listinfo/zope-dev )
