> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>
> 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?
Not all. If populator "knows" the sub-set of nodes that should come with the
current request than only those are affected. So, if you expect an input
from a checkbox and you don't get it then you set according value to false.
If you don't expect it then you don't touch it.
Is it a little clear?
> 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?
Partial submit can be possible of the client is an Xforms-enabled browser,
otherwise it would require some hacky JavaScript along with hidden fields
and even worse - hidden frames.
I am agree that client will need to "add" or "delete" nodes in instance.
This can be handled using the event model from Xforms. E.g., if our request
handler gets an "add" or "delete" event then it should "know" also which
nodes are affected by that event then after that perform the instance update
operation (add or remove nodes, update values).
> 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?
Seems that I've lost you here.Where do you see a limitation? Are you for
"knowing" the set of nodes to expect or not? ;)
For the Gender example: it doesn't matter how to input UI field look like,
is a radio or a combo box. The relevant part is that it is a single
selection node and you should be present in the request from that form. But
I am agree, that depending on the UI type this param should be handled
differently: in case of a checkbox - the parameter presence is relevant,
while for the radio it's not as it will always be present. So, the algorythm
can be as this (in case of a singleSelect input field):
- check of the parameter is present
- if not - set the value to 'null' (or maybe 'false'?)
- if present - get the value from it and set to the according node
in instance
>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.
What do you mean by "standart hidden input solution"?
> Can anyone enlighten me?
At least I've tried ;)
>
> <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.
So, we will have an object model of the form. And yes, forms can be really
large.
What other think of this?
>
> <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?
Exactly
> 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.
Yes, this kind of validation also needed. By "data dependency" I meant also
this type of validation. This is also addressed by XForms binding
expressions and <isValid> elements. Though, I'm not sure that current XPath
implementations support XForms like functions.
>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).
I think that we will leave client-side validation and focus/blur handling
for the future, when we'll have more or less working server-side handling.
>
> 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...
Sure
>
> 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.
Note, that 'relevan't contraint is not required to be present for every
input field. Say, a checkbox group can be always 'relevant', but not
'required', so you can deselect all the boxes and get no request param. As
I've said, this can be solved by "knowing" that there _must_ be a param. If
it's not there then set it to 'null' or maybe another default value.
>
> <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
Constraints can contain functions.
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.
Thanks for comments.
Regards,
Konstantin
>
> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
