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
Date Tue, 21 May 2002 05:12:16 GMT

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


<snip/>

> > Are suggesting that the flow layer with the addition of some kind of
> > Schematron processor could completely replace XMLForm?  And if so, could
> > you elaborate why you think this would be a better solution?
>
> With respect to the ability to handle user input for editing an XML
> document, if you look at the functionality provided by the two, they
> are very similar. Nothing prevents implementing an XMLForm-like
> processor on top of the control flow engine. Whether this would be
> better I don't know, I can't say anything until such a thing is
> implemented. I was just observing that the overlap between the two
> things.
>
> > Also, are you thinking of something like Rhino on the server so that
> > validation could be done by similar javascript on both client/server?
>
> Yes, the current control flow layer uses a modified version of Rhino
> on the server side. It should be possible to write the validation code
> directly in JavaScript, and have it run both on the server and on the
> client browser.
>
> 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.
>
> > Finally, I think transforming Schematron to javascript could be very
tricky.
> > Something like <assert test=".!=''"> might be easy enough to transform,
> > or even <assert test="/NAME_PREFER!=/NAME_ALIAS_FIRST">, but what about
> > <assert test="not(contains(translate(.,'!@#$%^&amp;*()_+-=0123456789','
> > ************************'),'*'))">
> > The nasty problem here is that the "conditional" part of an assert
> > is unparsed character data, not xml markup, and so (almost) impossible
> > to transform.  Seems like you would need to use a constraint description
> > language that expresses more of its content in "pure" XML (perhaps
XMLSchema??).
> > Or perhaps some even more abstract XML "model/constraint expression
syntax"
> > which could be translated into XMLSchema, Schematron, or client/server
> > javascript as needed, i.e:
> >       <validation-rule>
> >             <validation-test>
> >                   <instance-node name="LAST_NAME" type="String" />
> >                   <contains>!@#$%^&amp;*()_+=0123456789</contains>
> >             </validation-test>
> >             <message>Last Name contains an illegal character.</message>
> >       </validation-rule>
> > (A very crude example, but you get the idea...)
>
> Yes, this is what I had in mind. You're right, transforming a
> Schematron document in JavaScript could be a difficult task. A
> constraint language as you describe above would be better, since
> writing a translator to JavaScript is much easier. However the
> expressiveness of such a language is lower than that of an XPath-based
> description.
>
> 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.
I am speculating that XML standards will be better supported in the long run
than ECMAScript based languages.


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