docs: Improve Validation docs

[neznaika0]

Description
I do not know, is this more of a "bug or a feature"? It looks like a hidden feature.

I think few people use validation with objects. Do you think it's worth updating the documentation? If so, please check the translation.

I can't say exactly which version this will work from, but the current 4.5 branch shouldn't have any problems. I tested on 4.5.5 and 4.2.12

• Show an example of object validation
• Show how an object can be validated before creation
• Add note. With the addition of DataCaster in the Model, the validation of objects is relevant
• Show examples of storing rules in objects instead of the Validation property
• Feature PR. Pass setRules(), check(), run() [class, method] or invokable class-string to the validator instead of an array.

Checklist:

• Securely signed commits
• Component(s) with PHPDoc blocks, only if necessary or adds value
• Unit testing, with >80% coverage
• User guide updated
• Conforms to style guide

[neznaika0]

We need to review the draft. Otherwise, I will not continue further.

[michalsn]

If the user guide doesn't mention validation data other than from the form, this should be changed.

Such a possibility was introduced somewhere in v2. In v4, the class name was changed to Validation to avoid implying its use only with forms.

I don't see anything new in your example - you are simply using a custom validation rule outside the controller.

This is good material for a blog post, but I personally don't see the need to add it to the user guide.

[neznaika0]

Right. It's about improving the user experience.
In that case, should we open additional categories for the blog? For example, Best Practices or Use Cases?

Personally, I have recently applied this improvement. Judging by the questions on the forum, many people do not use basic templates at all when working. These are additional checks, the use of constants, service(), model()... So they use a small part of the framework.

I've been using this for a long time to check a captcha, but I didn't immediately realize that I would be able to check something outside the form

[michalsn]

When I mentioned a blog post, I meant more like your personal blog. I think we abandoned the idea of having a "blog" on the official website.

[neznaika0]

Yeah, there seemed to be a topic about News/Blog.
Unfortunately, I can't write posts in English. A good option is to have a repository with Markdown and different translations.

I'll think about it. Now the PR will wait for the feedback of others and close it.
Thanks

[neznaika0]

@kenjis @paulbalandan @datamweb Can you write your opinion?

[datamweb]

@neznaika0 I read Technical Writing for Software Developers by Chris Chinchilla a few months ago, and I believe that the CodeIgniter4 documentation aligns well with the principles outlined in the book. Overall, CodeIgniter’s documentation is clear and practical, which is one of its strengths.

In my opinion, anything that enhances clarity and helps users better understand and utilize CodeIgniter’s features is worth adding to the documentation. However, we need to be cautious about overloading it with unnecessary details and focus on adding only what genuinely benefits users. If these proposed changes are presented concisely and purposefully, they could contribute to improving the documentation.

Therefore, I suggest incorporating these points into the documentation, while ensuring that the explanations are precise and fully relevant.

That said, the opinion of the maintainers is crucial since they have spent a significant amount of time working on CodeIgniter. Adding advanced documentation might pose challenges for maintenance in the long term, so it’s important to carefully consider and coordinate these additions with them.