[Patternfly] Form field relationships

[Jonathan Yu]

On Sun, Jan 29, 2017 at 12:27 PM, Harald Pehl <hpehl at redhat.com> wrote:

>
> Some attributes have relationships to other attributes. Basically
> there are two different kind oif relationships:
>

This is a pretty common requirement, but sadly I haven't found anything
sophisticated enough to handle these sorts of multi-field validations -
most libraries focus on individual fields (this field is required, this
must be an email address, etc) but not constraints between them (this field
is required only if another optional field is set).

If you're using traditional forms (that is, submitting to server side as a
POST), I'd suggest using something like this:

1. Requires: One attribute requires another one
>

Add an input handler to the first input, and on every change, determine
whether to show/hide the corresponding field. For example, if you are
collecting a State for addresses in the United States, but only country
otherwise, then you can add an oninput handler to the country field and
show/hide the corresponding field by adding/removing the "hidden" class and
"disabled" attribute (to prevent it from being submitted with your form).
For best results, you'll also need to replicate the logic on the server
side (or figure out a way to share them, since I see you're using GWT).

If you have multiple fields, which are optional (if all are left blank) or
required (if any one of them are filled in), I suggest hiding them behind a
checkbox control that corresponds to a condition like "my billing address
and contact address are different", where checking the box should unhide
several controls and mark them all as required.

>
> 2. Alternatives: Alternative attributes are mutually exclusive. Only
> one attribute can be set.
>

If you start typing in one field, either disable or hide the other field,
to make it clear that only one of them can be modified at a time. You can
also use a dropdown or radio input for this.

I think you hit on the right thing in your design doc about progressive
disclosure, and ideally you have someone versed in interaction design to
help you design the right workflow for your use case, as I don't think
there's any one-size-fits-all approach. In my opinion, there's no
substitute for user research.

Jonathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/patternfly/attachments/20170129/87f9b941/attachment.htm>