cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivelin Ivanov" <ive...@apache.org>
Subject Re: Flow and XMLForm [LONG]
Date Wed, 22 May 2002 02:32:04 GMT

Both of you have good points, guys.

I am not sure what is the answer to these tough questions.
And I certainly don't mind any further extensions that will benefit Cocoon
users.


I can only say that the next thing I'll be working on is to show how XMLForm
can be used to write REST oriented Web Services.
Before I started commiting code to Cocoon, I was looking for a framework
which will allow web apps to be written and then web services enabled with
little effort. This is a real business drive for me for real enterprise
projects.

The functionality is already in XMLForm. What is missing is a good test
case.
I hope the feedback wizard is a decent example of how user interactive pages
are written.
Now I am  planning to use AntEater to demo how the wizard can be used as:
1) Web Service
2) remote portal plug-in. RSS has been successful for static remote content.
It's time to show how interactive forms can be embedded remotely.



Regards,

Ivelin


----- Original Message -----
From: <mratliff@collegenet.com>
To: <cocoon-dev@xml.apache.org>
Sent: Tuesday, May 21, 2002 4:19 PM
Subject: Re: Flow and XMLForm [LONG]


>
> 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
>


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


Mime
View raw message