Return-Path: Delivered-To: apmail-xml-cocoon-users-archive@xml.apache.org Received: (qmail 15179 invoked by uid 500); 29 Jan 2003 05:41:32 -0000 Mailing-List: contact cocoon-users-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-users@xml.apache.org Delivered-To: mailing list cocoon-users@xml.apache.org Received: (qmail 15168 invoked from network); 29 Jan 2003 05:41:31 -0000 Message-ID: <025c01c2c759$2446ed40$0100a8c0@robertgame> From: "Robert Simmons" To: References: <024a01c2c754$e794e3b0$0100a8c0@robertgame> <200301291325.47768.niclas@hedhman.org> Subject: Re: XMLForms Versus Traditional HTML forms. Date: Wed, 29 Jan 2003 06:41:58 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Yeah .. well I meant the XMLForms samples. And I still haven't found those. The other samples I found easily. -- Robert ----- Original Message ----- From: "Niclas Hedhman" To: Sent: Wednesday, January 29, 2003 6:25 AM Subject: Re: XMLForms Versus Traditional HTML forms. On Wednesday 29 January 2003 13:11, Robert Simmons wrote: > Hmm .. I cant seem to even find the samples on my cocoon installation. Are > they not in the current binary distribution ? Provided you have dropped the cocoon.war into $TOMCAT_HOME/webapps, you should find samples in; $TOMCAT_HOME/webapps/cocoon/samples/ Niclas > -- Robert > > ----- Original Message ----- > From: "Kirchhoff, Lars" > To: > Sent: Wednesday, January 29, 2003 5:09 AM > Subject: AW: XMLForms Versus Traditional HTML forms. > > > But why you need then cocoon for? If you just use traditional html > isn't cocoon a bit to much? i'm just curios? Wouldn't it then better > just use jsp or something similar? > > The main advantage of cocoon and xmlform for me is still to create > a xml document, which then can be transformed through the pipeline > in nearly every possible format. This means creating applications or > websites, which can serve multiple devices. > > Especially for xmlforms there is a strong seperation of concerns, > which in the first moment and for small application is a bit to > much, but helps to divide the programming of the actual dataflow and > business logic from the presentation layer and keeps the code > manageable. I don't like to mix up any program code with tags from > either xml or html. That's why I use and tried xmlform and don't > feel comfortable with xsp. > > Of course you can transform the xmlform tags to html form tags, > as long as there are not to many browser out, which are > understanding xforms, which are still in draft. > > BTW does anybody know an reference implementation of an xforms > browser? > > regards > Lars > > > -----Urspr�ngliche Nachricht----- > > Von: Robert Simmons [mailto:derisor@arcor.de] > > Gesendet: Mittwoch, 29. Januar 2003 11:50 > > An: cocoon-users@xml.apache.org > > Betreff: Re: XMLForms Versus Traditional HTML forms. > > > > > > Well actually I already have some generators running to fetch > > data from the > > database. I have put that data in manually. Now I want to do > > it dynamically. > > Simplicity wise I should use "conventional" forms, but I am > > not sure if that > > is the "right" way to do it. > > > > -- Robert > > > > ----- Original Message ----- > > From: "Niclas Hedhman" > > To: > > Sent: Wednesday, January 29, 2003 4:39 AM > > Subject: Re: XMLForms Versus Traditional HTML forms. > > > > On Wednesday 29 January 2003 11:16, Robert Simmons wrote: > > > Greetings. I would like to know what people favor using. > > > > > > By my, admittedly limited, knowledge, the traditional HTML > > > > forms will still > > > > > work with cocoon as the request will still have access to the data. > > > Alternatively if I use XMLForms, I'm not sure how much > > > > learning effort Id > > > > > have to invest. I read the XMLForm tutorial at > > > > http://xml.apache.org/cocoon/howto/xmlform-wizard/howto-xmlfor > > m-wizard-3.ht > > >ml and am still a but unclear how I define how the form will be rendered. > > Does the user have control over that at all? If I use HTML forms then I > > would be imbedding a form into an XSL transform which would print out the > > form for the user. > > Slightly beyond my experience (I also use 'conventional' approach), but I > see > it as; > > 1. The XMLForm generator creates a XML document of the POST request. > 2. You can aggregate that with other XML documents, static or dynamic. > 3. Feed that to the transformer(s). > 4. Output > > Meaning, the main advantage would be that you can do a fair amount of logic > on > the posted request in XSL (XSL is Turing complete, right?), without writing > any Java/XSP code. For some people (those who know XSL better than Java) > that > is more power with less hazzle. > > Niclas > > --------------------------------------------------------------------- > Please check that your question has not already been answered in the > FAQ before posting. > > To unsubscribe, e-mail: > For additional commands, e-mail: > > > --------------------------------------------------------------------- > Please check that your question has not already been answered in the > FAQ before posting. > > To unsubscribe, e-mail: > For additional commands, e-mail: > > --------------------------------------------------------------------- > Please check that your question has not already been answered in the > FAQ before posting. > > To unsubscribe, e-mail: > For additional commands, e-mail: > > > --------------------------------------------------------------------- > Please check that your question has not already been answered in the > FAQ before posting. > > To unsubscribe, e-mail: > For additional commands, e-mail: --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. To unsubscribe, e-mail: For additional commands, e-mail: --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. To unsubscribe, e-mail: For additional commands, e-mail: