cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mratl...@collegenet.com
Subject Re: HEADS UP - cocoon form handling (long!!)
Date Thu, 11 Apr 2002 00:32:34 GMT

 Hello,

<disclaimer>I have just joined this news group so I'm not sure this message is
going to end up in the right thread.  I'm going to cut and paste some context
from Konstantine Piroumian's latest post, just in case.</disclaimer>

I have been following the form handling discussions for some time now ("lurking"
is the term, I guess)  and would like to ditto most of what Konstantine Pirouman
has written.  Particularly about using XForms markup.  I have just a few things
to add...

Konstantine mentioned the advantages of using XForm markup.  I would like to
emphasize that  XForms adresses a very broad range of possible use-cases, and
that, even if there *never* is a client-side XForms processor, XForms markup
provides a valuable abstraction layer for form descriptions processed by the
server (SoC, device independence, etc.).  You can have a single form description
that gets processed through  one pipeline into XHTML and through another
pipeline into something radically different like a Flash movie (check out
http://reservations.broadmoor.com with a Flash 5.0 enabled browser), and through
another
pipeline into something like "XForms on the client" (i.e. a javascript/XHTML
implementation of XForms similar to Mozquito).  Again, as Konstantine has said,
why develop your own markup when one is available?

I am also completly in agreement (if I understand him) with Konstantine's idea
to use XForms markup as meta information during forms processing.   If anything
I am more enthusiastic than he  about using XForms markup for the  entirety of
the form description.  But I don't entirely understand what he means by
"use[ing] XForms markup for the presentation part (view)".  Perhaps he is
referring to XForms elements like "toggle" or "switch/case" that control the
view in an XForms enabled client?  Anyway, I think even these may be useful
abstract constructs that can be transformed into the desired target markup using
xslt.


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message