Page tree
Skip to end of metadata
Go to start of metadata

Goal

Make these easy, fast, clear, powerful to implement:

Concept

1. Introduce the ability to supply logical expressions which can use the values of other fields in order to determine the state on a field.

Expressions might be javascript, or an expression language like MVEL.

Maybe expressions are indicated by parenthesis.

( isWizard & ( hasSpellSlots | hasWand))

Maybe expressions would also have access to some context such as the current user group and role, so that some fields would only be visible or enabled to certain user roles.

2. Consider ways to augment fields, potentially with Java, that do not require creating brand new fieldTypes. Creating fieldTypes is harder, slower & less transparent then augmenting a fieldType with some custom behaviour.


Question

Is there a nice way that for any thing that can take an inline expression, it could also take a "link" to an external javascript function, or to a java class?

ie enabled, visible, label, buttonLabel, options

Would we need to add additional properties like enabledClass, visibleClass....?

Features

Dynamically Enabled

The enabled property can take a logical expression as well as a simple boolean value.

fields:
	isBarbarian:
		fieldType: checkbox
		type: Boolean
	isElf
		fieldType: checkbox
		type: Boolean
    barbarianElfHatType:
		fieldType: text
		enabled: ( isBarbarian & isElf )
        description: What type of hat is your elven barbarian wearing?

Dynamically Visible

A field is only visible on a form, if the  "visible" expression evaluates to true.

Could also be called "present" instead of "visible".

fields:
	barbarianElfHatType:
		fieldType: text
		visible: ( isBarbarian & isElf )

Dynamically Validated

Expand the regexp validator to be able to operate not just on the current field, but to include values from other fields.

Introduce a new "expression" validator which can take a logical expression, and which can include values from other fields.

By placing at the field level, devs would have control of where validation messages and hilights appear.

fields:
	clericSpells:
		fieldType: text
		validators:
            onlyClericOrWizard:
              class: info....ExpressionValidator
              expression: (!(clericSpells!="" & wizardSpells!=""))
			  errorMessage: Only Cleric OR Wizard spells allowed, not both.


Dynamic Label & Dynamic Button Labels

TODO.

Use expression, Javascript or Java, to determine which hardcoded string is displayed, or which i18n key is retrieved.

For example this can be used with a Static field, to provide a label that reacts to things selected in other controls.

"This combination of herbs soothes your mind and promotes concentration".

Dynamic Options

Populate the options of a selectbox, set of radiobuttons, or twincolumn select, based on the value of other fields.

We provide some out-of-the-box modes where no custom coding is required, but also make it easier for developers to fulfil this use case with a minimum of coding for more custom use cases.


dynamicSelect Field and optionModel Class

Developer provides a Java class or a Javascript function which takes the values of the fields specifed in "optionModelArguments" as arguments, and returns an array of label & value pairs to populate the options field with.

Options list is empty until the "optionModelArguments" fields have values.

fields:
	heroType:
		fieldType: select
		options:
			- wizard
			- cleric
			- fighter
			- thief
	level:
		fieldType: select
		options:
			- 1
			- 2
			- 3
			- 4

    spells:
		fieldType: dynamicSelect
		optionModelArguments
			- heroType
			- level
		optionModel: org.dandelion......AvailableSpells
        description: Choose from your available spells, after choosing your heroType and level.

Another example:

fields:
	country:
		fieldType: select
		path: /
		repository: countries

    state:
		fieldType: dynamicSelect
		optionModelArguments
			- country
		optionModel: org.dandelion......StatesPerCountry

    postalCode:
		fieldType: dynamicSelect
		optionModelArguments
			- state
		optionModel: org.dandelion......PostalCodesPerState

Node Chooser

Out-of-the-box fields based on a heirarchy of nodes. (Possibly JCR bound.)

introduce two new dynamic field types:

dynamicNodeLink:

A link field which gets its workspace from another field.

dynamicNodeSelect:

A selectbox which gets its options based on a parentNode from another field.

By default it only returns the immediate children.


fields:
	myWorkspace:
		fieldType: workspace

	myParentNode:
		fieldType: dynamicNodeLink
		workspace: myWorkspace
		nodeTypes:
			- mgnl:folder

    assets:
		fieldType: dynamicNodeSelect
		parentNode: myParentNode
        includeAllDecendants: true
		nodeTypes:
			- mgnl:asset


Note: Can we make this ContentType-centric instead of JCR-centric so that it is usable OOTB on external content sources?

Notes

Take a look at linked tickets on:  MGNLUI-2542 - Getting issue details... STATUS


It would be useful to have a Super-link field where I have a first select box to choose a workspace "tours, pages, contacts", and then a link field below it that lets me choose an item from that workspace.


From:  Dynamic forms and cross-field validation

  • populating select options based on the value of another field
  • validating a field depending on the value of another field (including within a composite field itself)
  • enabling/disabling fields conditionally
  • updating form buttons (enabling/disabling/relabeling)


Filtered Multi Select Choose Dialog


It would be good to ask a support representative:

Maybe Rich or Mercedes.



  • No labels

1 Comment

  1. Nice one, some form of expressions seem to be quite appealing indeed (smile), few more food for thought:

    • seems to work well, especially combined with boolean traits; declaring such attributes "on the spot" reminds me of JSF ELs used in XML-like attributes
    • we could add more such boolean traits (a visible property on fields sounds legit)
    • I would tentatively go for a less technical syntax, e.g. rather with literal AND , OR , NOT EMPTY , etc. We're in a declarative context; that's not backed by a DSL, then users wouldn't be tempted to write arbitrary code, it's not code.
    • re: dynamic labels, using the field abstraction for those was always unfortunate, maybe we can replace that with a description extension to fields
    • and/or with a generic way of describing pattern matching hierarchically in YAML? (that one would serve dependent selects as well)