cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Simmons" <deri...@arcor.de>
Subject Re: XMLForms Versus Traditional HTML forms.
Date Wed, 29 Jan 2003 04:37:01 GMT
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" <Lars.Kirchhoff@wincor-nixdorf.com>
To: <cocoon-users@xml.apache.org>
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" <niclas@hedhman.org>
> To: <cocoon-users@xml.apache.org>
> 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:     <cocoon-users-unsubscribe@xml.apache.org>
For additional commands, e-mail:   <cocoon-users-help@xml.apache.org>


---------------------------------------------------------------------
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:     <cocoon-users-unsubscribe@xml.apache.org>
For additional commands, e-mail:   <cocoon-users-help@xml.apache.org>

---------------------------------------------------------------------
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:     <cocoon-users-unsubscribe@xml.apache.org>
For additional commands, e-mail:   <cocoon-users-help@xml.apache.org>


---------------------------------------------------------------------
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:     <cocoon-users-unsubscribe@xml.apache.org>
For additional commands, e-mail:   <cocoon-users-help@xml.apache.org>


Mime
View raw message