nova-flexible-content compatibility and more

[RobertoNegro]

Hello, in one of my projects I use whitecube/nova-flexible-content which saves the repeatable fields in a json. The problem is that nova-items-field requires an already-parsed json and since this is not the case with flexible-content it does not work.

To solve this, I've added a check on the type of the field value and if it's a string it parses it.

With nova-flexible-content there is also another problem: you don't know exactly the attribute name since it's prefixed by a group key generated internally by the library (since the field is repeatable the prefix is used to identify exactly the instance of the field).

So, I've changed the definition of the rules to allow to skip the attribute name.

For example

Items::make('Emails')->rules([
    null => 'required|min:2'
    '*' => 'email|min:10',
]),

is equal to

Items::make('Emails', 'user_email')->rules([
    'user_email' => 'required|min:2',
    'user_email.*' => 'email|min:10',
]),

This is handled during the validation, so with nova-flexible-content it handles correctly the attribute name with the randomly generated prefix.

I've also updated the readme with this example.

And, as you can see in the example, I've also managed to allow validation on the array to check if there are at least or at most N items etc.

There was also another problem with the names of the attributes containing dots (e.g., flexible_input.0.attributes.x_conditions), because the validator expected an array due to the dots in the name while instead in the input the attribute name contained the dots in the key, so I've simply swapped . with -> during validation and then reverted the replacement.

As a bonus, I've also changed how the details view is presented to show the items as a list since, in my opinion, makes more sense

In general, these changes are not interfering with a normal usage of the library without nova-flexible-content, with the only exception that now it works even if you don't apply the cast 'attribute' => 'array' on the model, but I think that's not a bad thing, and now you can avoid to repeat the attribute name on the rules (without breaking the previous behaviour), which I think is also a good thing.

Probably, these changes allow also to use this component with other libraries that manipulates the fields in a json-format, like translatable etc, but I haven't tested it.

[bashgeek]

Thanks a lot! This has been implemented now, but I had to make some changes to it, so I cannot merge this PR itself - thanks for your very detailed explanation.