Reusable controls / control templates / validations

[ebruchez]

Say you have a Yes/No selection you need to use in many place in your form. You shouldn't have to re-create the itemset every time.

Possibilities (non-exclusive):

• create a predefined set of such common controls (e.g. Yes/No)
• allow author to save a selection control and/or just itemset to the toolbox (how to persist this though? class in the form? what about reusing for a new form?)

[evlist]

I have the problem for a customer who fetches common itemsets from a database (countries, salutations, ...). Wouldn't a simple solution be an option to "reuse" the same itemset than another control?

[avernet]

It would be possible. But what if you delete that other first control with the "master" itemset? Would the other controls that were referring to that itemset become "itemsetless", or should we migrate the itemset to one of the remaining controls?

I think it would make more sense to have such itemsets defined independently of the control (through something in the left sidebar), and then allow a control to reference such an itemset instead of entering it inline.

[ebruchez]

Yes and in fact we might soon implement, as par of work for a customer, a mechanism in the XForms engine to define itemsets completely independently from controls. This could be a basis for this feature.

[evlist]

@avernet : we could have a warning message asking what to do but I agree that this looks like a hack... @ebruchez : another more generic option would be to allow to define control templates (like we have section templates). In that case that wouldn't be the itemset that would be shared but the definition of the select or select1 (or any other control). By convention any form called "library" can be used as a set of section templates and we could say that all the controls within a section called "library" or "controls" in this form would be considered as control templates in the same way. That would be useful not only for select and select1 but also for any control with complex XPath expressions or whatever needs to be shared to facilitate form maintenance.

[ebruchez]

I am extending this RFE to controls beyond selection controls. For example, we want to add a "Regular Expression" common constraint. Say you worked on that constraint on a specific control. Now it makes sense to be able to reuse that, in the current form or between forms.

One idea would be to be able to take any control and say "save to library". The library could be:

• local to the form
• per Form Runner app
• global

It would make sense to be able to store that in the current library forms for the app/global cases. Right now we only store complete sections there.

Implementation ideas:

• The control used as template would be copied/pasted to the library. Somehow, the component should show not as a section template, but as an individual control. All relevant aspects of the control would be copied, like in the case of a regular copy/paste.
• form-to-xbl.xsl would create XBL components not only for the sections, but for the individual controls identified.
• Form Builder would need the ability, from a given form being edited, to read, modify and write a library form, as you wouldn't want to require going to the library form as a prerequisite.

Q: How would we make a distinction, in the library form, between sections to expose as section templates, and other sections? Maybe we would create a special section at the beginning, which would be used to store these custom controls.

[ebruchez]

We now have a "Yes/No Answer" control, so that one is taken care of. But we have another +1 from evaluator for a generic solution.

[avernet]

+1 from evaluator

[ebruchez]

What this would be useful for:

• Controls with preset itemset, like a Gender control.
• Control with preset validations, like with a particular regex or warnings.
• Control with a built-in local action, like loading an itemset.
• More?

[ebruchez]

It would be nice if we could add a component to the library directly from a form definition. But this should also be the case with section templates. So we can make that a P2.

As a first step, we can do this in the acme/library and orbeon/library forms. A special section would contain controls, each of which would become its own XBL component.

Steps:

• [ ] decide how special section would be identified
  • alternative: use different "library" form definition
• [ ] write equivalent to update form-to-xbl.xsl
• [ ] toolbox must load such XBL components in a new area of the toolbox

[avernet]

+1 from user

[ebruchez]

+1 from customer

[ebruchez]

+1 from evaluator

[ebruchez]

Reviewing this, it does seem that the library forms are a possible place for that. A "library" can contain section templates, but also reusable components.

This opens some questions:

• Q: Are components "by reference", like section templates, or copied?
• If "by reference"
  • Q: Is there a merge option like for section templates?
    • A: Probably yes!
  • Q: How would we handle validations? Create a local model?
    • A: This would make sense: the component would be fully encapsulated, like section templates.
• Q: Could the form author do this directly from a given form definition?
  • A: Only as a P2.
• Q: From a UI perspective, how are the components separated in the section template?
  • A: Maybe internally use a well-known section name (orbeon-components-section). The UI could then decide to show/hide that in a better way, maybe as P2.

Items to include in the component:

• view content (including custom CSS classes)
• bind content (validations, etc.)
• resources (i18n, including static itemsets)
• P2: actions and services, like for section templates

[ebruchez]

There could be multiple sections, or sub-sections, of custom controls, in the library form. This would allow grouping the controls under headings in the toolbox.

[ebruchez]

• Maybe: add option to have a preferred control name when inserting in the form.
• Maybe: overrides, such as just overriding the label; replacing a default validation?
• First implementation: no composite controls (made up of several individual controls)

[avernet]

+1 for reusable validation, so if a given validation rule is used on several fields, possibly across forms, and the requirement for this validation changes, the change only needs to be done in a single place, to save time and potential mistakes.

+1 from customer

[ebruchez]

Another use case: Currency control, set currency prefix, for example GBP, and make it a reusable control with that specific currency.

Although for that use case, could we imagine a currency directly configurable from the toolbox? Or, for selected controls a quick configuration at the top of the Form Builder form area or toolbox?

[ebruchez]

+1 from customer