Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Subject: Re: Flow and XMLForm [LONG]
To: cocoon-dev@xml.apache.org,
	Torsten Curdt <tcurdt@dff.st>
Message-ID: <OF1BFF84BD.2E6F37C7-ON88256BC1.0058D2C5@collegenet.com>
From: mratliff@collegenet.com
Date: Wed, 22 May 2002 10:25:21 -0700
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii


Torsten,

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

> That's exactly the goal of the precept idea...

Hmmm... I looked at precept stuff early on, but liked the way Schematron
handled phases.  I'll take another look...

<snip>
> > Maybe supporting such media in Cocoon is pretty distant, but
> > supporting usability in general shouldn't be:  usability is an issue *now*.

> Not at all. I have already written a FlashTranformer and a FlashSerializer and

> am about to put them in scrachtpad (or should I put them directly into the
> main trunk?) Problem is that the flash stuff is based on project that lacks
> developers and is not that far yet. But it's a good starting point...
> I just try to push that project a little so it's enough for a little example.
> ...don't expect much of it yet(!!) (As far as I heard SWF is a complete
> nightmare)

The pace of innovation in this group is amazing.  Don't know how anybody keeps
up.
Wish I could help on this one, but I'm too busy with forms stuff for now...

<snip>
> > 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
>
> Sorry, I don't wanna be picky - but "we" have chosen IIRC

I apologize for not crediting you properly.

<snip>

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

> Well, actually my idea was to define validation more expressive so we can even

> generate client side javascript validations! This should work quite easy if
> you look at the precept example. I see the problem in a different area:
> schematron  - all you have are XPathExpression constraints. Easy to come up
> with, but - you only know that a specific XPathExpression failed. This
> doesn't give useful information for clientside validation. If you had
> different type of constraints e.g. a regular expression constraint that
> failed this could be easily translated it into javascript by a stylesheet.

Regex constraints are more flexible because you can pass the regex string
to client javascript for evaluation?  What about non regex constraints?
I still need rule based constraints as in Schematron, but they need to
be represented in a way which can be translated into javascript (i.e. not as
non-parsed character data in the "test" attribute.)

<snip/>

> Unfortunately I am forced not to spent (too) much time on the form handling
> stuff currently (company's will) but be sure I am still working on it...

I plan to take another, closer look at Precept when I have finished my
excercises
with XMLForm.

--Michael


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