Mailing-List: contact users-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-Id: <7C6EC9550222914294F9F337038AB55ADD4887@uk-hemel.mail.saic.com>
From: "Smith, Lee [OS-IE]" <LEE.A.SMITH@saic.com>
To: "'users@cocoon.apache.org'" <users@cocoon.apache.org>
Subject: Continuations and cleaning up
Date: Thu, 4 Nov 2004 02:28:37 -0800 
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

Hey All,

New user to cocoon here, and I've got a question about the use of
continuations in flow scripts.

I'll explain my question with the following block of code:

 1: function myFunc()
 2: {
 3:    var myDB = Database.getConnection("myPool");
 4:    myDB.setAutoCommit(false);
 5:
 6:    .. do some work on the connection, don't commit
 7:
 8:    cocoon.sendPageAndWait("confirm_changes.html");
 9:    
10:    if (cocoon.request.getParameter("confirm_changes") == "true")
11:       myDB.commit();
12:    else
13:       myDB.rollback();
14:
15:    cocoon.sendPage("change_made.html");
14: }

In this example I get a connection to a database, make some changes and then
allow the user to confirm they are happy with the changes and then depending
upon their response, either commit them or roll them back.

Now this is all fine assuming the user follows the confirmation or
cancellation links on the page - however, assuming there is a menu system on
the confirmation page it is possible for the user to break out of the
continuation without completing it, hence leaving uncommitted changes in the
database.

Is there anyway I can trap the user activating links on the site (assuming
they activate another resource in the current site-map)? I have a feeling I
may be thinking about this in too much of a Java-ish way and there should be
another way I should be doing this :)

I'm expecting somebody to say "Why not let the user confirm any changes
before applying them to the database", well the reason for doing this is it
allows me to trap any errors (ie. things like duplicate keys, or invalid
foreign keys) that show up when you apply the changes to the db and then
show these to the user before I ask them if they are happy with the changes.

Anyway, thanks in advance for any advice :)


Lee

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