Increase textfields maxlength about dkan

[dafeder]

@stefan-korn yeah this is a good point. Hmm. Since this field is used for URLs 128 does seem very stingy. What do we think of

1. Setting the maxlength by default to be 512, which seems likely to accommodate most URLs someone would be using here. Alternatively, is there a way to explicitly set no maxlength, like set it to zero or null? I can't find any reference to this in the docs.
2. Having handleStringElement look for a maxlength property in the schema and apply that instead if present.

I don't know that I think we should make this settable in the UI schema. UI schema is supposed to extend what can be inferred from the schema itself, not prevent input that would otherwise be allowed by the schema, or override limits that are present in the schema. We generally try to follow the model of react-jsonschema-form and they do not allow setting maxlength via ui schema.

[dafeder]

cc @paul-m who I think has been active in the Drupal core issues about this

[stefan-korn]

@dafeder : You surely know, but if you set schema property "format" to "uri" for a string field, the maxlength will increase to 255. That is because the JSON Form widget uses a drupal "url" form element then (same for pattern property which translates to email form element).

So urls are not direcly related to this issue, only plain text fields. But if you want to extend it even to 512 then "uri" has to be tackled too.

[dafeder]

Actually missed that, thanks for the clarification. 256 is probably still plenty for 99% of use cases, maybe let's just start with that as the default for all textfields?

[stefan-korn]

How about PR #4168. This would increase the limit just for "textfield" elements provided by JSON Form widget.

[stefan-korn]

maybe leave a hint or ToDo pointing to https://www.drupal.org/project/drupal/issues/3331028 in the code comments?

[stefan-korn]

@dafeder : While fixing the tests in #4168 I came across ArrayHelper. There is buildSimpleArrayElement which builds a texfield without maxlength too. Not sure if maxlength should be set there too?

[stefan-korn]

@dafeder : I changed the place of injecting maxlength from StringHelper to WidgetRouter. Injecting in StringHelper is problematic, because the WidgetRouter might change the type "textfield" to something else, i. e. Date Time widget and there the maxlength is causing trouble. Therefore injecting maxlength only after the WidgetRouter has done its changes and the type is still textfield.

[stefan-korn]

Hm, this is way more complex than I have thought. ArrayHelper and ObjectHelper together with the "add one" button do their own thing in some way.

I'm now tending to solve it for our project on a general base with hook_element_info_alter for all textfields regardless whether they are from JSON Form Widget or anywhere else.

[dafeder]

Hmm that is unfortunate... I will have to take a closer look at what's happening. I'd be open to bringing this in if it addresses the problem in most places and has test coverage and documents remaining open issues. But maybe needs a higher-level refactor to properly fix?

[stefan-korn]

Yes, maybe some refactoring would help to solve it in the JSON Form Widget. Probably it will have to happen in the StringHelper, but then in the WidgetRouter one would need to remove the maxlength for those widgets that are changing the type again. I tried to avoid this, because this is kind of a trap when implementing new widgets for example. But since the fields without a widget do not touch the WidgetRouter, it cannot be solved directly in the WidgetRouter.

And above mentioned buildSimpleArrayElement should probably also go to StringHelper and not directly provide the textfield type.

But surely it is questionable if it is worth the effort, when core maybe changes this later on.

But from JSON Form Widget point of view, there would be no maxlength necessary at all, since everything is stored in the JSON field. So maybe the other way round, just kicking maxlength out (as you have mentioned above and I have not noticed until now) might be a better approach. Still this is also not straightforward I am afraid.