TypedInput string validation

Core Development
1

Hey devs,

i got some problems with the string validation in the TypedInput widget.
The validation is not working for my TypedInput of type string.
it should work like described here

my example:

...
defaults: {
  atContext: { value: '', required: true },
  atContextType: { value: 'str' },
...
// and somewhere in the onPrepareEdit:
$("#node-input-atContext").typedInput({ types: ['str'], default: 'str' })

did i miss a flag for non empty strings?
image

The same procedure with JSON typedInput works.

EDIT
and the correct HTML class is beeing generated, but somehow its not shown.

image
image1110×192 19.4 KB

EDIT2
image
with an own definition type and validation its working

const strType = {
                value: "string",
                label: "String",
                icon: "red/images/typedInput/az.svg",
                validate: /^(?!\\s*$).+/
            }

$("#node-input-atContext").typedInput({ types: [strType ], default: 'string'})

is it a bug or am i missing something ?

2

It is more a limitation of the validation system, rather than a bug. (Although that's a matter of perspective and interpretation and just be splitting hairs...)

When validating values, the editor doesn't know 100% how that property is represented in the UI. It looks for a <input> with the expected id (based on the property name). If it finds one, then it sets the css class on that input.

In the case of a TypedInput, the <input> with that id is actually an internal hidden input. But the editor doesn't know that field is being represented by a TypedInput.

As a 'feature enhancement' (rather than bug fix), it wouldn't be unreasonable to add TypedInput awareness to that editor code, so that in this scenario to applies the class to the right element.

3

thx for the explanation.
Why is it working then with the JSON type ? Isn't here everything similar ?

4

The TypedInput has its own built-in type validation for some types.

When it comes to a String type however, a blank string is a valid string. The TypedInput doesn't know what extra requirements you have set on the node property.

5

I see.
Would it then make sense to enhanced the default options in custom nodes for an attribute like 'emptyValueAllowed' or one with a better name...

atContext: { value: '', required: true, emptyValueAllowed: false },

which the typedinput could interpret, if the built-in types have been adjusted ?

Because i think an empty value can be a valid case for every type here.
For json type:
if an empty value is allowed ->
i would generate an empty object which can be parsed. This would reduce the need of manual input.

if an empty value is not allowed ->
i would forbid an empty input and an empty json object '{}'

6

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.