Lets not lump cocoon to "XMLForms or no XMLForms." Nor should we pick out any other one feature of cocoon and say that if you don't use this feature you shouldn't use cocoon. Nor should we say something like "if you aren't going pure XML XSL XSP that you shouldn't use cocoon. Cocoon is a toolkit and you should pick those tools appropriate to your use. I chose cocoon over JSP because I get the multi format content and clear separation of logic and presentation. To me, a form is presentation.
As for multi-content, I could easily write a transform that converts things to WML based forms. Its a matter of taste. Its also a matter of necessity. I have already spent too long working on the presentation layer to my project and I don't care to invest another month. I am not merely a learner but a professional with tight deadlines. I'm not sure its worth the extra effort. But the "not sure" is why I posted the question. If I was sure, I wouldn't have posted. Another thing is if it is in draft than that would be one reason for me to do it the old way. Real business applications require something that works. That isn't always the same thing as something that is "cool". -- Robert ----- Original Message ----- From: "Kirchhoff, Lars" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]] > Gesendet: Mittwoch, 29. Januar 2003 11:50 > An: [EMAIL PROTECTED] > 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" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > 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. <http://xml.apache.org/cocoon/faq/index.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]> --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]> --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]> --------------------------------------------------------------------- Please check that your question has not already been answered in the FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html> To unsubscribe, e-mail: <[EMAIL PROTECTED]> For additional commands, e-mail: <[EMAIL PROTECTED]>
