RE: FW: XForms how-to

Hello Roland.

> 2) The element <name /> should not be readOnly, as you state 
> the user needs
> to be able to supply a value. We supply two form controls 
> which you should
> use. <input /> should be used in the circumstance that the 
> user is allowed
> to change the value and <output /> should be used when you 
> wish to display
> the value but not allow it to be changed.

I have several arguments against the solution you offer:
  a) The suggested default rendering of the xforms:output element is
html:span, not readonly html:input. Of course, I could use the "class"
attribute to decide how to render the xforms:output element. But if I
understand it well, the "class" attribute is to denote the semantic meaning
of the element (e.g. class="name"), not how the element is to be rendered
(e.g. class="html-input").
  b) Imagine you have fields for two persons in a form and a checkbox that
denotes whether the second person is the same as the first one:
	<person-one />
	<person-two />
	<both-persons-are-equal xsd:type="boolean" />
When the (corresponding form-control) checkbox is checked, I want to copy
the values from "person-one" to "person-two", but I don't want to allow the
user to edit the values for the second user. If the checkbox is not checked,
the values for "person-two" should be freely editable. As the specification
doesn't differ between modifications from the corresponding form-control and
by an xforms:action, it is impossible (in my opinion) to copy the values
from "person-one" to "person-two" when the checkbox is checked (when having
e.g. <xforms:bind ref="person-two" readOnly="yes"
relevant="both-persons-are-equal = true()" />).
  c) In some cases, it seems to me much more natural to put the "readOnly"
constraint onto the form-control instead onto the corresponding
data-element.

> 3) I'm not sure what you are asking here. If an element is 
> required to have
> a value and none is supplied then any form control bound to 
> that element
> will need to explain that the required constraint has not 
> been satisfied.
> If no form control is bound to an element which requires a 
> value and for
> which none is supplied, this is an authoring error which the 
> user cannot
> fix.

I understood the "required" attribute as "null value cannot be send to the
server" rather than "the user himself has to supply the value". If the
second interpretation is closer to the truth (=the official interpretation),
you are right, this would be an authoring error. But I interpret (maybe
wrongly) the form instance as "the form itself" and the form controls as "a
mere visualization" - trying to distinguish between the purpose and the
presentation. Hence, the "required" constraint could be put even onto an
instance-data element that doesn't have a form-control counter-part.

> 4) If you application requires information from two sources and that a
> subset the "blended" combination is submitted, then this 
> could be tackled
> by merging the two inputs into a single instance at the server (i.e.
> outside the scope of XForms) and designing the merged 
> structure such that
> the appropriate subset can be specified by the "single node binding
> attributes" of a submitInfo.

No, I meant to have one source only. Perhaps I explained it not clearly
enough:
Consistently with the interpretation "form-instance is primary,
form-controls are secondary", the server should not care about what form
controls are contained by a particular form (which is a thing of
presentation), it should supply only those values that are relevant to it
(e.g. those that it can find in the database). Hence, the form can contain
also form-controls that the server doesn't know about - and hence didn't
supply values for them. But as to each form-control an instance element must
correspond, the form has to contain instance data that were not supplied by
the server. The supplied and non-supplied data cannot be put into one common
xforms:instance, and as each xforms:model element can contain one instance
at most, there must be at least two model sections in the form document.
This will cause problems when submitting, because each xforms:submitInfo is
tied to one particular xforms:model section.

	Thanks,
			Martin.

Received on Tuesday, 29 January 2002 11:02:49 UTC