GithubHelp home page GithubHelp logo

Comments (15)

dafeder avatar dafeder commented on September 26, 2024 1

See PR comments, I am going to make my own attempt at a solution to this elsewhere in the module.

from dkan.

dafeder avatar dafeder commented on September 26, 2024

@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.

from dkan.

dafeder avatar dafeder commented on September 26, 2024

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

from dkan.

stefan-korn avatar stefan-korn commented on September 26, 2024

@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.

from dkan.

dafeder avatar dafeder commented on September 26, 2024

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?

from dkan.

stefan-korn avatar stefan-korn commented on September 26, 2024

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

from dkan.

stefan-korn avatar stefan-korn commented on September 26, 2024

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

from dkan.

stefan-korn avatar stefan-korn commented on September 26, 2024

@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?

from dkan.

stefan-korn avatar stefan-korn commented on September 26, 2024

@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.

from dkan.

stefan-korn avatar stefan-korn commented on September 26, 2024

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.

from dkan.

dafeder avatar dafeder commented on September 26, 2024

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?

from dkan.

stefan-korn avatar stefan-korn commented on September 26, 2024

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.

from dkan.

stefan-korn avatar stefan-korn commented on September 26, 2024

@dafeder : There is another issue that arises in this context, but not related to textfields maxlength directy.

The base field filePath of ResourceMapping entity is defined as a string field, resulting in database length of 255 chars for this field. DKAN D7 allowed for such a URL to have length of up to 2048 chars. So if you do a harvest from a DKAN D7 instance you may end up in an error during the harvest if the source URL is longer than 255 chars.

I suppose changing the base field definition to "uri" instead of "string" would solve this on the harvesting side without having any side effects hopefully. It would allow to harvest a long URL and it would also not get lost during saving the dataset.

Though it would still not be possible to enter a URL longer than 255 chars via the UI because maxlength of the textfield is still 255 chars.

What do you think? Should I create a separate issue for the change in the ResourceMapping entity?

from dkan.

dafeder avatar dafeder commented on September 26, 2024

@stefan-korn sorry just caught this last comment. Yes that makes sense. Feel free to make a new issue for it/submit a PR.

I'm revisiting your PR here, I think it would be worth doing a fix like this even if there are still remaining issues.

from dkan.

dafeder avatar dafeder commented on September 26, 2024

@stefan-korn ok tried again implementing via stringhelper and then adding an unset when needed to overwrite with other widget types, that seems reasonable. Let me know what you think. It seems to trickle down into objects and arrays as well but haven't tested that quite as extensively yet.

from dkan.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.