Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 29370 invoked from network); 28 Feb 2000 12:15:10 -0000 Received: from tele-post-20.mail.demon.net (194.217.242.20) by locus.apache.org with SMTP; 28 Feb 2000 12:15:10 -0000 Received: from media.demon.co.uk ([158.152.20.147] helo=192.168.0.2) by tele-post-20.mail.demon.net with esmtp (Exim 2.12 #2) id 12PP4u-0000EP-0K for cocoon-dev@xml.apache.org; Mon, 28 Feb 2000 12:15:08 +0000 Date: Mon, 28 Feb 2000 12:10:50 +0000 From: Jeremy Quinn Subject: Re: [announce] XMLForm - a new project using Xerces, Xalan, & JTidy To: cocoon-dev@xml.apache.org X-Priority: 3 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; Charset=US-ASCII X-Mailer: Mailsmith 1.1.4 (Bluto) Message-Id: X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N On 27/2/00 at 3:11 pm, balld@webslingerZ.com (Donald Ball) wrote: Donald, Thanks for starting this off. I am sure you understand that I am not chastising you for having produced the "wrong thing", we just have different goals. What you produced fired my imagination as to how this could be done within Cocoon and why. >On Tue, 22 Feb 2000, Jeremy Quinn wrote: >> On 21/2/00 at 4:24 pm, balld@webslingerZ.com (Donald Ball) wrote: >> Sorry to say this, considering how much work you have already done, but >could >> this Form handling functionality be considered for inclusion into Cocoon? >> If so, how should it interact with SiteMap, XSL and XSP? > >It's possible, I suppose, but I think a marriage would be forced, at best. >I see the two projects as complementary. What advantage would be gained by >putting this functionality inside cocoon itself somewhere? I feel that a generic way of handling form input is important to Cocoon. Publishing forms and and handling the data they generate involve all the same issues of content|logic|style separation that any other publishing project requires. I don't see any reason why this functionality should _not_ be integrated into Cocoon. :) > >> >From the README file in the distribution. >> > >> > >> >> Is this not a bit of a security hole? Anyone with the motivation, >> could "explore" your XML file structure (with feedback from error >> messages) and add Nodes wherever they like; just by modifying the >> Form. (In fact I have some students who might think of this as fun :) > >Well, I wouldn't open up the XMLForm servlet to untrusted users. Ah Ha! Here is the difference between us .... I see the need for a generic solution, one that is inherently secure and does not need hiding away. One that could be safely used by anyone for any task, however sensitive. Maybe one person will use it for sending search requests to the server, maybe someone else will use it to allow users to make new pages on their site. It should not matter. We just have different design goals .... >Cocoon is a web publishing framework. And Forms are a component of web publishing ... >XMLForm doesn't need cocoon since it >only returns HTTP redirects (unless something goes wrong). I understand, though I am thinking (aloud) about whether the need is the other way around. >I'm all ears, otherwise I say keep the code and feature bloat to a minimum ;) Absolutely! OK, I am probably going to put my foot in it here .... this is just a first stab What I think I am trying to do, is work out if it would be possible, or even desirable, to come up with a DTD for a FormGlue.xml file that would contain the all the information required to specify every stage in the process of publishing and handling Forms. I want to do this because these are issues that will need to be solved if Bugoon is to get off the ground. How do I see seperation working with Forms? Logic Contract What data is to be captured? What are the fields called? Where is that data to go? (XML Fragment, SQL db, email msg etc.) How does the data need to be transformed to fit the storage? What are the constraints on the data? (form checking) Style Contract How should it look? What different formats should the form be output in? (HTML, WAP etc.) Content Contract What are the default values for the form? What should you get when you fill in the form correctly? What is the content of the page the form is in? What processing needs to happen (due to my flawed understanding of how this will be effected by the SiteMap and XSP, this is probably garbage :) The Form is rendered Authorisation? (optional) Choose Browser (optional) Collect page content (based on user-lang or some other context) Collect Form Field default values (based on user-lang or some other context) Collect Form Field "inherited" values (optional) (Maybe someone is editing or correcting existing data or form submission) Assemble the Form The Form is submitted Authorisation? (optional) Convert PostArgs (or "GetArgs") into an XML Node, using "glue" to define which Field goes into which Element. Check the data. too long, too short, coercable to correct data-type, valid URL, whatever ... Data Action (optional) Storage: static or calculated FilePath, XPath expression, SQL connection defs, email address, etc. Trigger: Method to invoke with Form XML Maybe we are controlling a Robot or linking to a Merchant Server Generate response Send back the pre-filled form, with error messages if incorrect Redirect to, or assemble response page or chain to next Form (pre-filling accepted data into hidden fields) Basically, if this functionality is not built into Cocoon, we will all be re-inventing the wheel .... whenever we need forms in our sites. Maybe I am only seeing my little bit of the Forest :) (English expression: Can't see the wood for the trees) I hope this makes sense to SOMEBODY! :) regards Jeremy ____________________________________________________________________ Jeremy Quinn media.demon webSpace Design