cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From mratl...@collegenet.com
Subject Re: Flow and XMLForm [LONG]
Date Tue, 21 May 2002 21:19:29 GMT

Hello,

> From: "Ovidiu Predescu" <ovidiu@apache.org>
> To: <mratliff@collegenet.com>
> Cc: <cocoon-dev@xml.apache.org>
> Sent: Monday, May 20, 2002 10:03 PM
> Subject: Re: Flow and XMLForm

<snip />
> JavaScript client validation improves the user experience quite a bit,
> so I think a validation solution should generate both client and
> server side validation code.

<snip />
> Yes, but that doesn't solve the problem for current browsers that
> don't support XSLT (Opera, Konqueror? etc.), or for older browsers,
> which support JavaScript only, or WAP, iMode, and many other browsers
> integrated in small devices. IMO Cocoon should be able to reach these
> not so mainstream browsers as well. And do a good job at supporting
> them, by providing the their users with the best possible user
> experience.

Ovidiu has a point here.  Javascript is widely supported in browsers, available
for PDA's
(http://industry.java.sun.com/javanews/stories/story2/0,1072,41318,00.html) and
wireless devices (WMLScript).   Usability is a key feature of any forms
technology.  Just point a Flash 5.0 enabled browser at
http://reservations.broadmoor.com/ to see usability on steroids.  Consider that
there are already xml converters which produce binary .swf (.cfm) files.  Maybe
supporting such media in Cocoon is pretty distant, but supporting usability in
general shouldn't be:  usability is an issue *now*.

Here's a *basic* form using client side javascript:
      http://www.applyweb.com/public/contribute?cmsccard
Yes, you could do all the validation/calculation server side, but there are so
many dependencies that pressing the "calculate" button could result in multiple
interrelated errors.  (Quantity must be greater than 3 if "Imprint" is true; sum
of all imprints must be less than 70; all Quantities must be numeric; all
Amounts must be floats rounded to hundredth; Total depends on Imprint Total
which depends on Quantities and Imprint, etc.  And this is a *basic* form.)
Maybe all such form "behaviors" could be implemented on the server for embedded
internet devices, but browser users demand a much higher degree of usability.

The current incarnation of XMLForm could not directly handle a form like this
one; neither could any XForms equipped browser that I have seen (including the
most recent version of XSmiles).  The XForms language itself has pretty limited
syntax for expressing dependencies and calculations. Ivelin has choosen to
support a subset of XForms behavior on the server- a useful limitation.  XMLForm
plus authentication/authorization plus database integration should serve the
needs of many (most?) form developers.

But some form developers will require something like what Ovidiu has described.
Writing validation routines in javascript for both server and client grants the
developer a "behavioral flexibility" that XPath/Schematron just can't match.
Maybe no XML based language would have the necessary expressiveness.  The
problem is that the developer might pay a pretty high price for such
flexibility!   Create "custom" javascipt for *each* form?  Even using standard
validation libraries this would take far more effort than writing Schematron
rules.  How can such a process scale?

I think there are potentially three broad use-cases, and possible three
different form module solutions:
      1) USE_CASE: "simple" forms:  forms with one or a few "views", limited
behavioral repetoire, relatively "simple" validation rules, straightforward
usability requirements.  SOLUTION: Precept, XML Form,  a combination of these?
      2) USE-CASE: "complex" forms: forms with many (10-20) views, dozens of
widgets per view, complicated behavioral requirements, complex validation or
depenedency rules, or usability "issues".  SOLUTION:  flow engine with
javascript validation ?? something else ???
      3) USE-CASE: "industrial forms".  Same as complex forms but even more so,
and with the additional requirement that form development must scale.  Hundreds
or thousands of forms developed, supported, and maintained per year.  SOLUTION:
(I think) must emphasize form components written in "pure" XML markup (leverage
contenxt checking, document validation, helper technologies) rather than java or
javascript.

But as Thoreau says, "one world at a time".  XMLForm is useful *now*.  Anyone
interested in forms should check it out in detail.  I just asking:  isn't there
room in Cocoon for more than one way to handle forms?  Could any one forms
"solution" handle all the wacky kinds of forms out there?  Shouldn't  there be a
simple solution for people who need to handle "simple" forms, a more complex
solution for people who need to handle "complex forms" (and are willing to pay
the price) and an even more complex solution for people who need to handle
"industrial forms" (and are *really* willing to pay the price).  Or do my
use-cases #2 and #3 simply exceed the bounds of what Cocoon was/is intended to
do?

Cheers
--Michael



                                                                                         
                     
                      Ovidiu Predescu                                                    
                     
                      <ovidiu@apache.or        To:       "Ivelin Ivanov" <ivelin@apache.org>
                  
                      g>                       cc:       cocoon-dev@xml.apache.org    
                        
                      Sent by:                 Subject:  Re: Flow and XMLForm            
                     
                      ovidiu@uxho0309.c                                                  
                     
                      up.hp.com                                                          
                     
                                                                                         
                     
                                                                                         
                     
                      05/20/02 11:04 PM                                                  
                     
                      Please respond to                                                  
                     
                      cocoon-dev                                                         
                     
                                                                                         
                     
                                                                                         
                     




On Tue, 21 May 2002 00:12:16 -0500, "Ivelin Ivanov" <ivelin@apache.org> wrote:

> ----- Original Message -----
> From: "Ovidiu Predescu" <ovidiu@apache.org>
> To: <mratliff@collegenet.com>
> Cc: <cocoon-dev@xml.apache.org>
> Sent: Monday, May 20, 2002 10:03 PM
> Subject: Re: Flow and XMLForm
> >
> > So there are three ways an XMLForm-like capability could be
> > implemented:
> >
> > - translate today's XPath-based Schematron to JavaScript scripts for
> > both client and server side
> >
> > - translate a constraint expression syntax, not based on XPath, to
> > JavaScript for client and server side
> >
> > - write the validation functions in JavaScript, same scripts being
> > used on the server and client side.
> >
> > I don't know about you, but the last approach looks to me being the
> > easiest one to implement (basically write your scripts). One problem I
> > see with it though is ties the validation to JavaScript, making it
> > difficult to support clients that don't run JavaScript, like browsers
> > on WML phones (although the language used is very similar).
>
> Just a note in regard to client/server side validation.
> New generation browsers support XSLT.
> Which means that Schemtron validation can be run on the client as well.
> Haven't tried it myself.

Yes, but that doesn't solve the problem for current browsers that
don't support XSLT (Opera, Konqueror? etc.), or for older browsers,
which support JavaScript only, or WAP, iMode, and many other browsers
integrated in small devices. IMO Cocoon should be able to reach these
not so mainstream browsers as well. And do a good job at supporting
them, by providing the their users with the best possible user
experience.

> I am speculating that XML standards will be better supported in the long run
> than ECMAScript based languages.

Supporting standards usually takes a very long time, you cannot assume
everybody will support the latest standards. Even then, you still have
to support older browsers that don't adhere to the latest
standards. Just look at how many JavaScript versions and variations
are in today's Web browsers; it's a total mess! Nevertheless, good
service providers try to support them all.


Regards,
--
Ovidiu Predescu <ovidiu@apache.org>

>>> I'm in the job market again, check out my resume and qualifications at:
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)

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






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


Mime
View raw message