Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 50069 invoked from network); 8 Jun 2004 16:12:32 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 8 Jun 2004 16:12:32 -0000 Received: (qmail 10859 invoked by uid 500); 8 Jun 2004 16:12:09 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 10583 invoked by uid 500); 8 Jun 2004 16:12:07 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 10532 invoked by uid 99); 8 Jun 2004 16:12:04 -0000 Received: from [130.237.222.202] (HELO smtp.nada.kth.se) (130.237.222.202) by apache.org (qpsmtpd/0.27.1) with ESMTP; Tue, 08 Jun 2004 09:12:04 -0700 Received: from nada.kth.se (fw96.lentus.se [192.58.197.96] (may be forged)) (authenticated bits=0) by smtp.nada.kth.se (8.12.10/8.12.1) with ESMTP id i58GBgt4023496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 8 Jun 2004 18:11:42 +0200 (MEST) Message-ID: <40C5E53D.9070309@nada.kth.se> Date: Tue, 08 Jun 2004 18:11:41 +0200 From: Daniel Fagerstrom User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: [cforms] Simple XML binding Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N I have written an adapter: org.apache.cocoon.forms.util.XMLAdapter between a form object and a simple XML format that can be used without needing to wriite a binding definition. In the applications where we have used cforms we mostly have connected the form objects to XML through the binding framework. While the binding framework has a lot of flexibility in how to bind the form to DOM, we usually have used a more or less 1-1 coupling between DOM and the form. So the flexibilty of the binding framework feels in our applications like overkill and writing the bindings unnecessary. --- o0o --- The XML format is such that there is one XML element for each widget and the element get the widget id as name. Exceptions from this is that the elements in a repeater gets the name "item" and a attribute "position" with the position of the repeater child, instead of just a number (which is not allowed as element name). Childs of a MultiValueField are also embeded within an "item" element. If the Form widget does not have an id it get the name "unknown". I added the possiblity to give an id to the Form widget. An AggregateField can both be interpreted as one value and as several widgets. This ambiguity is resolved by chosing to emit the single value rather than the fields as XML. For population of the form both forms are however allowed. XMLAdapter implements XMLConsumer and XMLizable, so it can be used both as a SAX source and destination. I added a utility function to forms.js: getXML(), that returns the widget wrapped in an XMLAdapter. A typical flowscript can look like: function form2simpleXML(form) { // get the documentURI parameter from the sitemap which contains the // location of the file to be edited var documentURI = cocoon.parameters["documentURI"]; // get the XML adapter var xmlAdapter = form.getXML(); // parse the document to a widget tree var pipeUtil = cocoon.createObject(Packages.org.apache.cocoon.components.flow.util.PipelineUtil); pipeUtil.processToSAX(documentURI, null, xmlAdapter); // show the form to the user until it is validated successfully form.showForm("form2-display-pipeline"); // show the xml generated from the form cocoon.sendPage("form2simpleXML-success-pipeline", xmlAdapter); } I also checked in a sample, (a variant of the binding sample), that show how to use the adapter. WDYT? /Daniel