Improve specificity of errors in validate-txexpr #15

Makes validate-texpr recursive and tries to be as specific as possible about the problem:

;; This txexpr has two problems
(validate-txexpr `(fine-outer ((id "top") (class "42")) (div (p (span [["type" "1"]] ,(void) )))))
validate-txexpr: attribute key is not a symbol
  attribute key: "type"
  in: '(span (("type" "1")) #<void>)

;; After fixing the first one
(validate-txexpr `(fine-outer ((id "top") (class "42")) (div (p (span [[type "1"]] ,(void) )))))
validate-txexpr: element not a valid element (= txexpr, string, symbol, XML char, or cdata)
  element: #<void>
  in: '(span ((type "1")) #<void>)

Also fixes cases where errors can sometimes be misleading; for example, in the current version:

;; Problem is malformed attrs in p tag, but error points at 1st element of fine-outer
(validate-txexpr  '(fine-outer "no problem" "\n" (p [[href "#"] class "hidden"] "Hello!")))
validate-txexpr-attrs: contract violation
  expected: 
   in '(fine-outer "no problem" "\n" (p ((href "#") class "hidden") "Hello!")), list of 
attributes, each in the form '(symbol "string")
  given: "no problem"

In this version:

(validate-txexpr  '(fine-outer "no problem" "\n" (p [[href "#"] class "hidden"] "Hello!")))
validate-txexpr: attribute is not a list of the form '(symbol "string")
  attribute: 'class
  in: '(p ((href "#") class "hidden") "Hello!")

Makes `validate-texpr` recursive and tries to be as specific as possible about the problem: ```racket ;; This txexpr has two problems (validate-txexpr `(fine-outer ((id "top") (class "42")) (div (p (span [["type" "1"]] ,(void) ))))) validate-txexpr: attribute key is not a symbol attribute key: "type" in: '(span (("type" "1")) #<void>) ;; After fixing the first one (validate-txexpr `(fine-outer ((id "top") (class "42")) (div (p (span [[type "1"]] ,(void) ))))) validate-txexpr: element not a valid element (= txexpr, string, symbol, XML char, or cdata) element: #<void> in: '(span ((type "1")) #<void>) ``` Also fixes cases where errors can sometimes be misleading; for example, in the current version: ```racket ;; Problem is malformed attrs in p tag, but error points at 1st element of fine-outer (validate-txexpr '(fine-outer "no problem" "\n" (p [[href "#"] class "hidden"] "Hello!"))) validate-txexpr-attrs: contract violation expected: in '(fine-outer "no problem" "\n" (p ((href "#") class "hidden") "Hello!")), list of attributes, each in the form '(symbol "string") given: "no problem" ``` In this version: ```racket (validate-txexpr '(fine-outer "no problem" "\n" (p [[href "#"] class "hidden"] "Hello!"))) validate-txexpr: attribute is not a list of the form '(symbol "string") attribute: 'class in: '(p ((href "#") class "hidden") "Hello!") ```

Thanks. I like this. Could you add a few tests however?

Test that a certain flaw raises the expected descriptive message.
Test that a certain flaw raises the same message regardless of where it appears (e.g., even deeply nested).
Would be possible or desirable to have a version of validate-txexpr (or a keyword option) that checks the whole txexpr for errors, and reports the list of errors at the end (as opposed to bailing out after the first error, which is the right behavior in most cases, but I can see the other kind being useful too)

Thanks. I like this. Could you add a few tests however? 1. Test that a certain flaw raises the expected descriptive message. 2. Test that a certain flaw raises the same message regardless of where it appears (e.g., even deeply nested). 3. Would be possible or desirable to have a version of `validate-txexpr` (or a keyword option) that checks the whole txexpr for errors, and reports the list of errors at the end (as opposed to bailing out after the first error, which is the right behavior in most cases, but I can see the other kind being useful too)

Test that a certain flaw raises the expected descriptive message.

Test that a certain flaw raises the same message regardless of where it appears (e.g., even deeply nested).

Would it make sense to replace the existing tests with these?

> 1. Test that a certain flaw raises the expected descriptive message. > 2. Test that a certain flaw raises the same message regardless of where it appears (e.g., even deeply nested). Would it make sense to replace the existing tests with these?

Add rather than replace, I think (to ensure that the upgrade doesn’t change the existing behavior))

Great thanks!

Labels Milestones

Improve specificity of errors in validate-txexpr #15

Step 1:

Step 2: