Commit graph

8 commits

Author SHA1 Message Date
Henrique Moody
cfeb01e89e
Bump respect/coding-standard from 4 to 5 2025-12-18 19:03:39 +01:00
Henrique Moody
7f66bcea10
Bump PHP support from 8.1 to 8.5
We want to release version 3.0 as fresh as possible, without having to
maintain backward compatibility with the previous versions. Because that
version will be on for some time, we decided it will be best to support
only PHP version 8.5 or higher.

Acked-by: Alexandre Gomes Gaigalas <alganet@gmail.com>
2025-12-18 19:03:38 +01:00
Fabio Ribeiro
0e8ac1817b
Rename Result->isValid method 2025-03-31 21:29:37 +02:00
Henrique Moody
1915b6fff7
Use paths to identify when a rule fails
When nested-structural validation fails, it's challenging to identify
which rule failed from the main exception message. A great example is
the `Issue796Test.php` file. The exception message says:

host must be a string

But you're left unsure whether it's the `host` key from the `mysql` key
or the `postgresql` key.

This commit changes that behaviour by introducing the concept of "Path."
The `path` represents the path that a rule has taken, and we can use it
in structural rules to identify the path of an array or object.

Here's what it looks like before and after:

```diff
-host must be a string
+`.mysql.host` must be a string
```

Because paths are a specific concept, I added a dot (`.`) at the
beginning of all paths when displaying them. I was inspired by the `jq`
syntax. I also added backticks around paths to distinguish them from any
other value.

I didn't manage to fix a test, and I skipped it instead of fixing it
because I want to make changes in how we display error messages as
arrays, and it will be easier to fix it then.
2024-12-27 23:28:35 +01:00
Henrique Moody
82cb05b197
Handle siblings when creating messages
The way we display messages could have been better, and it took me a
while to realise that to make it better, I would need to handle the
siblings of a result before deciding whether we should render it.

Another issue was that rules like Key and Property had to create a
"dumb" parent just so we would display the messages correctly, and in
some cases, that wasn't even enough.

This commit introduces quite a few changes to how the library works,
making the messages much more straightforward.
2024-12-13 02:34:27 +01:00
Henrique Moody
d356696af9
Upgrade translation mechanism
Currently, defining translations is quite cumbersome, and the translator
callback is passed to the constructor of multiple classes, which makes
it quite ugly and could make translations inconsistent.

This commit completely changes how translations are done in Validation.
Instead of using a callback, it uses a specific class, and `Validator`
will pass that object through the objects that render the messages.
2024-12-05 15:42:40 +01:00
Henrique Moody
fefe905e0b
Include "__root__" when getting message as an array
When converting an object into an array, we exclude the message root
message from it. Since we're using a convention to template those
messages as an array, we could also use the same convention to return
those messages.

While working on it, I noticed that the name "__self__" wasn't
reflecting what that really meant, so I renamed it "__root__" because it
better reflects the meaning of those messages/templates.

Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
2024-03-25 22:38:19 +01:00
Henrique Moody
238f2d506a
Update validation engine
There are a few "problems" with the current engine:

- Allowing each rule to execute assert() and check() means duplication
  in some cases.

- Because we use exceptions to assert/check, we can only invert a
  validation (with Not) if there are errors. That means that we have
  limited granularity control.

- There is a lot of logic in the exceptions. That means that even after
  it throws an exception, something could still happen. We're stable on
  that front, but I want to simplify them. Besides, debugging exception
  code is painful because the stack trace does not go beyond the
  exception.

Apart from that, there are many limitations with templating, and working
that out in the current implementation makes it much harder.

These changes will improve the library in many aspects, but they will
also change the behavior and break backward compatibility. However,
that's a price I'm willing to pay for the improvements we'll have.

Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
2024-02-22 16:54:44 +01:00