Tolerate invalid URLs in ADF

Issue #5 closed
Chris Fuller created an issue

There are cases in the wild of ADF containing values that are supposed to be valid URLs, but instead are empty strings (even in link marks, which should presumably want to require a value) or invalid in some other way (such as blob: URLs, whcih don’t have any meaning outside the web browser that created them).

While it’s highly questionable that such values exist at all, it isn’t really the purpose of this library to reject content that the editor will accept. As such, the library will need to be more tolerant of these cases. The plan is:

  • Change the internal field’s type from URL to String.
  • In cases where there is a setter that takes a URL, there is usually already one that also accepts a String and converts it to a URL for us. Both of these will remain strict (that is, the public setter for a String value will still validate that the URL parses and throw an exception if it does not).
  • However, an internal-only setter will be added that bypasses the URL validation, setting the String value directly and only performing any validation (such as minimum length) that is expressly called out in the schema.
  • Getters that return a URL object will throw a runtime exception if the underlying string value cannot be parsed to a valid URL. This also applies to cases where the value was Optional.
  • Additional getters with an ...AsString suffix will be added to get the raw String if desired; they will not validate their outputs.
  • The parse and toMap implementations will use the non-validating forms so that the values will be preserved even if they are invalid.

Another point worth considering is the background setting for tableCell and tableHeader. The library is currently restricting this to what is externally documented, that is, that it needs to be a “Short or long hex color code or HTML color name”. However, the schema does not enforce this, and in a discussion with the design team, it turns out that even though the specific cases where I saw it were accidental, they do fully intend for values like var(--ds-background-neutral, #F4F5F7) to be permissible. As a result, those validations also need to be relaxed.

Comments (3)

  1. Log in to comment