W3C home > Mailing lists > Public > public-xformsusers@w3.org > February 2016

Re: Whitespace processing during recalculate

From: Erik Bruchez <erik@bruchez.org>
Date: Tue, 16 Feb 2016 09:45:57 -0800
Message-ID: <CAAc0PEW3kkxN5CGwOMhLVHt2tMMHHnAMkRNuVKZbeaDifRiVHQ@mail.gmail.com>
To: Alain Couthures <alain.couthures@agencexml.com>
Cc: "public-xformsusers@w3.org" <public-xformsusers@w3.org>

> It remains me that XForms considers xsd:string for input/password controls while only xsd:normalizedString (no tab, no newline,...) is effectively supported

Good point.

And practically, as I was trying to make the case, it's even more
strict than xsd:normalizedString for most practical application, since
you want leading/trailing space trimming in most cases.

> Do you mean, for example, that, in incremental mode, the input value for the
> XForms control is always empty while the corresponding input field still
> contains just spaces? Is the input field just updated to the XForms value
> when focus is lost?

I haven't thought much about incremental mode but as things stand, any
update in the field in incremental mode would cause the model to
update soon thereafter, and so whitespace processing would take place,
and so the field would update back correspondingly (with trimmed
spaces). This might be a problem in some cases, and so you might not
want to enable whitespace trimming processing with an incremental
field and instead trim after the user tabs out.

> I think we should define a specific XForms data type for this case. This
> type could then be bound to nodes or defined as default.

Would the type cause trimming automatically, and if so at what point
in the processing model?

> We should always have a way to alter global engine options within a form.
> XSLTForms v1 allows authors to add processing instructions for that purpose.
> XSLTForms v2, because of HTML5, allows an <xforms-engine> element with
> attributes. Attributes such as model/version and model/functions sound to me
> more global options than options related to a specific model.

I agree on this (global vs. model). Not sure about how to do it best.


> What do you think?
> --Alain
> Le 11/02/2016 23:13, Erik Bruchez a écrit :
>> All,
>> We recently implemented an extension to do whitespace processing. I
>> think this might be of interest to XForms implementers. Blog post:
>> http://blog.orbeon.com/2016/02/required-fields-more-subtle-than-you.html
>> Doc:
>>      http://doc.orbeon.com/xforms/binds.html#whitespace-processing
>> -Erik
Received on Tuesday, 16 February 2016 17:46:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:37:45 UTC