Hello,
<disclaimer>Now I'm having trouble with my email program. It sent half of the
message I that intended. Here is the other half...</disclaimer>
<snip>
> > That's good. And this will require to create an object
> model of the form to
> > be able to iterate through its fields, according
> constraints, etc. This will
> > also help in cases, when there are not 'relevant' (see
> XForms 'relevant'
> > constraint) fields. This means, that not all the fields are
> necessary to be
> > taken into account for the current request depending on
> values of some other
> > fields (not sure that it's easy to implement, though).
>
> what do mean by "object model of the form"? I actually don't
> want to have
> always beans behind my forms. Is this what you are at?
Yes, that was the idea. Anyway, we need to know, as you've said, what to
expect from the current request.
</snip>
I still have don't entirely understand this "need". As I read Torsten's
original post, it is based solely on the "checkbox problem". And the solution
is for the populator to do something like: "I didn't get a value for node 'foo",
I was expecting a value, so set the value to null." Doesn't this mean that all
instance nodes must be submitted every time? Or they end up set to null?
Wouldn't it be useful to sometimes submit only a partial set of the instance
nodes? Isn't the client
in the best position to "decide" what instance data to submit? Maybe the client
will even *add* or *delete* instance data nodes. Or, what if you want to *one*
data validation module to process instance data from a variety of devices?
Wouldn't the server need to "know" that it sent "GENDER" as a checkbox
set to this device, GENDER as a radio set to that device, GENDER as a sprite
component to the other device, etc? It seems to me that if the server "knows"
what instance data to expect from the client that this limits what the client
can do with instance data, and how flexibly the server can process instance
data, so why do this? The standard "hidden-input" solution to this problem is
very much a hack, but it is a hack that can be limited to the client-types that
demonstrate the checkbox problem (by inserting it at the end of the pipeline in
a "presentation stylesheet" transform). But perhaps I am just confused about
all this. Can anyone enlighten me?
<snip>
There are two possibilities: create a
separate description (say, phases) or use the form description itself. If
we
create an object model of the form (not only UI, but also bindings) then
we
can simply iterate through form fields, validate according values from
request against a schema, then we can validate request against binding
contraints.
</snip>
I think you should eliminate phases and extract needed meta information from the
form description. With the caveat that
this might get tricky: form descriptions may be VERY LARGE.
<snip>
Ok, it's not a big issue, so let's keep Preceptor if you like it more. We
can change it in future.
</snip>
I also prefer Schema, or even "Validator" to "Preceptor". Preceptor sounds too
much like the title of a Romulan officer class :-)
<snip>
> > > There are two different parts of XML document validity:
> > > a) structure of the document
> > > b) content of nodes
> >
> > c) data dependency
>
</snip>
For the type of forms I see, instance-node validation has three steps:
1) data types validation. Does it conform to the data model (including
data types that have constraints). Is it alphanumeric? Is it <20 characters?
2) rule-based validation. Does it meet additional XForms or Schematron
constraints. Is it required? Is this value greater than the sum of that value
and some other value? Maybe this corresponds to Konstantine's #c) above?
3) procedural validation. Does it meet the test of some arbitrary
procedural code? If the total number of items is "x", then shipping cost =
f(x), if the total number of items is y then shipping cost is f(y), etc. This
type of validation is may be confused with business logic, but I consider it as
part of validation because there is a large class of forms that are almost
unusable unless this type of validation happens on the client as focus leaves a
UI widget (which is where validation often occurs).
Requirements for validation #1 and #2 may be described using XMLSchema and
embedded XMLSchematron rules. Possibly using XMLSchema and XForms constraints.
Requirements for #3 are difficult to describe at all: one needs some kind of
XML "procedural-expression syntax" and a graph of dependency relationships when
processing it. But I think it can be done... So perhaps you should at least
allow for the possibility that there will be a third type of validation
processing some day...
Incidentally, if we could get #3 to work for even a few simple use-cases, it
would really turbocharge Torsten's ClientJavaScript interface.
<snip>
Speaking frankly, I don't like the phase idea at all. It adds another
configuration file that should be supported and kept in sync with form
descriptors.
Let's find answer on this: is form description (descriptor) itself enough
to
determine the phase or simply the request params that should be taken
into
account during validation and instance update? Or: are the phase and
relevant params the same thing?
</snip>
I share Konstantine's dislike of the phase idea. Personally I would eliminate
the need for
phases by 1) using direct population of the instance and 2) using relevant
property bindings
in form description.
<snip>
Hm... Not very intuitive. I'd design it in a little different way, say:
return a collection of ValidationViolation objects and each of them can
be
of different types or have a field indicating the violation type. E.g.:
incorrect data format, required contraint violation, etc. Then we can use
the violation type to select the appropriate error message (this also
takes
into account i18n of errors).
</snip>
yes, much better
<snip>
Also, IIRC you've mentioned that validation should be two phase operation
(again those phases ;) ):
- data types validation
- contraint validation
The second phase should be skipped for those fields that didn't pass the
first one. So, we will need at least two types of objects indicating an
invalid state of data.
</snip>
to which I would add (potentially)
- procedural validation
see above
Let me finish by saying that I think the work both Torsten and Ivelin have done
is very cool. I offer these comments only because I am very interested in the
same problems they are trying to solve. Sorry, again for the format of these
posts. I'll try to be more intelligible next time.
Cheers,
--Michael
mratliff@collegen
et.com To: [EMAIL PROTECTED]
cc:
04/10/02 05:32 PM Subject: Re: HEADS UP - cocoon form
handling (long!!)
Please respond to
cocoon-dev
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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
