Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 16825 invoked by uid 500); 8 Mar 2001 21:19:33 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 16643 invoked from network); 8 Mar 2001 21:19:28 -0000 Date: Thu, 8 Mar 2001 16:19:33 -0500 (EST) From: Donald Ball X-Sender: To: Subject: database actions Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N heya. just testing berin's database actions out - good stuff! let me make sure i'm following the flow control properly - when a request for /forms/employee received, c2 checks to see if there's a request parameter named cocoon-action. if so, it fires off the proper action. in any case, it'll render the edit employee(s) form. correct so far? the database manipulation actions rely on a form-descriptor parameter which gives some meta-information about the table(s) in question, e.g.: personnel
yes? what's the benefit of grouping the actions together into an action set? - donald --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org