Piroumian
Konstantin To: "'[EMAIL PROTECTED]'"
<KPiroumian@prote <[EMAIL PROTECTED]>
k.com> cc:
Subject: RE: HEADS UP - cocoon form
handling
04/11/02 03:31 AM (long!!)
Please respond to
cocoon-dev
>> 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
>> 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?
I guess I wasn't clear myself. Lets say you have a multi-page form. One
instance data model
represented using XForms <model>...</model> markup. Any page will have only a
sub-set of the
instance data nodes in the total model. So my question is, do you need to
submit all the nodes
on any given page (a sub-set of the complete instance model)? If so, this seems
limiting to me.
I can think of all sorts of use-cases where I might want to submit only "some"
of the nodes
on a page, or may want to add nodes to the page before submission, or even
(crazy talk here)
submit nodes from a different page!
>> 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 disagree. There are all sorts of ways to do partial submits. Maybe I'm using
the
FlashMX plugin to display my form and I send an XML datagram to the server and
(I'm a
bit ignorant here) read the XML as a stream. This way I have a form that
submits
one field at a time, gets validation error messages back from the server,
doesn't
need to refresh the entire page, can do server side validation impossible to do
on client (like look up zip code in database and match to city), but has the
"immediacy"
and "usability" of client-side validation. Or maybe I have multiple form
objects
on my dynamic HTML page and some of them are in hidden DIV's. Each contains
a subset (of the subset) of instance nodes. I decide which to submit based on
user interaction. Or maybe I think I have a more clever way of doing Mozquito's
trick of getting client XForms to work in current browsers by sending big wad of
javascript to client (which I think is insane). So perhaps I'm using javascript
DOM
manipulation to create/destroy instance nodes on the fly and then submit
whatever
instance nodes are appropriate. This is not hacky, it is simple and elegant.
My real point is that these are all just differences of *presentation* (view).
If you
support an abstract form description, then I can figure out how to write a
pipeline of
transforms to produce these views and many others. Why should I be limited in
the
sort of presentation I can have because of something you are doing in the model
or
controller? This was what I meant about using the hidden-input hack to handle
checkboxes.
Since the way checkboxes submit is a feature/bug of particular device
implementations
(admittedly, most browsers using method="POST"), why not put the "fix" in the
"view" for
those particular device implementations?
>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).
Yes, but it seems like you are saying that when the client wants to add or
delete instance
nodes it will use XFroms event to tell server to make the changes. This seems
limiting.
I'm talking about client adding/deleting nodes at will, *immediately* and server
finding
out about it only when extra instance nodes arrive when submit. Like I have a
list of
items on screen corresponding to instance data nodes:
<item>foo</item>
<item>bar</item>
<item>whatever</item>
and a "more" button (maybe not even a button, maybe this is automatic or
something).
So when the user presses the button additional widgets for more items pop up
(*without*
going back to the server; I use javascript to manipulate the DOM directly and
add
new nodes as appropriate). The user now fills these in, and submits, and the
server
gets:
<item>foo</item>
<item>bar</item>
<item>whatever</item>
<item>this</item>
<item>that</item>
<item>the other</item>
Can I do this in the system you guys are proposing?
<aside>I think it is very important to have "behavior" on the client that does
not require a roundtrip
to the server. *Useability* is the number one complaint that *users* have with
forms. Without allowing
(or at least not precluding) scripted behavior on the client you run the risk of
solving the "forms problem" from the *developers* perspective without solving
the "forms problem" from the *users* perspective.</aside>
>> 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? ;)
I'm for the server not knowing what nodes to expect, but reacting to whatever
nodes it gets. But this,
in turn, is only because I have some vague, paranoid, SoC fears, and don't want
to be precluded from
any kind of wild form presentation I can imagine (read: make forms more usable,
intelligent, flexible,
by using client scripting and/or different media or devices).
I'm just trying to figure out if you guys:
1) don't see the same needs I do
2) see the same needs I do, but think the current design will meet them
3) see the same needs I do, but think the current design is a useful
(i.e., doable) limitation
>>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 "standard hidden input solution"?
Its a hack. Whenever you tranform instance data into a checkbox set that you
know is going out to a media/device that has problems with checkbox posting
(HTML in most browsers) you prepend a hidden input
field of the same name:
<input type="hidden" name="GENDER" value="" />
<input type="checkbox" name="GENDER" value="M" />
<input type="checkbox" name="GENDER" value="F" />
Now if both checkboxes are unselected, the server still gets GENDER="" in the
post. So it only sets instance
data (database, whatever) to null when GENDER is actually null, just like any
other form element. There are
a few other minor hacks associated with this approach, but basically it all
works without too much fuss. We
have been using it for five years, other companies have done similar. Maybe it
is not as "standard" as I thought?
>> Can anyone enlighten me?
>At least I've tried ;)
And I appreciate it.
>> 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.
I've looked at the XForms functions and XPath and they are do not quite meet my
needs.
Maybe I need to review the specs again and go "Hmmm...". The example I offered
was very simple.
Procedural validation often needs to be, well, procedural. Like to calculate a
total value you sum
the items times the costs, but then there are arbitrary rules about how cost
changes with
respect to number of items, and maybe you need to apply values that you get by
lookup in an
arbitrary table. So you end up having to manipulate data structures and control
flow
just to do this kind of validation. Only way I've managed to accomplish this is
to have procedural
javascript code on client that corresponds to procedural perl code on server
(for media/devices
that don't support javascript). Now, I would much rather have some kind of
declarative, XML based
expression syntax (part of form description?) that could be transformed into
whatever procedural
logic was needed, wherever it might be needed (i.e., on server or on client, in
perl, java, javascript
or what-have-you).
>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.
Understood, but you don't have to "solve" client-side validation. All you have
to do is not
prevent me from solving it! :-) Seriously, I think client-side validation is
largely an
issue of presentation. It can be "solved" by creating the right transformation
of
abstract form description tags into, for example, dynamic HTML/javascript. And
you end
up with a form that is much more "usable" than the typical "dumb" form.
Also understood: "the devil is in the details" and I can not claim to have
studied the details of
what Torsten and Ivelin have done. I'm just trying to understand better where
they're going with
all of this, and whether I can contribute anything to their efforts.
>> 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.
But again, I would like the *option* to allow the client be able to control what
is
relevant or reqired and to change these properties on the fly. The client would
take
care of making sure that when the request is sent that any data needing to be
posted
(even checkbox value==null) does get posted. The "hidden-input-hack" does this;
there may be other ways. And there are other media/devices that don't have the
hidden input problem.
>> 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
Yes, but my experience is that functions do not work in all cases.
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
Thank you for the edification.
Cheers,
--Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
