octobercms/docs

Is it possible to make the custom validation messages a bit easier to find in the doc's

summercms opened this issue · 8 comments

summercms commented

So I was reading the doc's and writing the following code in the models section php file.

Something like this:

class User extends Model
{
    public $messages = [
       'name.required' => 'The :attribute field is required.',
        ...
    ];
}

Basically I started my reading of the doc's here: https://octobercms.com/docs/services/validation#custom-error-messages

Tested it and it didn't work.

So I did some more digging through Google as the search engine in the October CMS website kept sending me to that page.

Thanks to Google after about 50 different searches I came across the Traits page here: https://octobercms.com/docs/database/traits#custom-error-messages

And found the following code:

class User extends Model
{
    public $customMessages = [
       'name.required' => 'The :attribute field is required.',
        ...
    ];
}

Is it possible to put on the main Validation page of the doc's a note saying October doesn't use public $messages and instead uses public $customMessages for adding custom messages to the models file.

I basically wasted an hour digging through all the doc's because it's kind of hidden away.

Also add an array example to the custom validation messages as well.

public $rules = [
        'links.*.url' => [ 'required', 'url' ],
];

public $customMessages = [
       'links.*.url.*' => 'Error with URL field',
];

and/or

public $rules = [
        'links.*.url' => [ 'required', 'url' ],
];

public $customMessages = [
       'links.*.url.required' => 'The URL is required',
];

etc.

LukeTowers commented

Feel free to submit a PR, this is why the docs are open source too

  • 👍1
summercms commented

@LukeTowers

image

Have the same content spread across a traits page and a validation page in the plugin section - would make things easier to find. Then I can expand both pieces of content with the array examples, is my suggestion.

Also the message found here: This section is for detailing validation with the Validator class. Validating a model is handled slightly differently via a trait. Please see the Validation Trait section for more information on validating models.

This section is for detailing validation with the Validator class. Validating a model is handled slightly differently via a trait. Please see the Validation Trait section for more information on validating models.

Could point to the Plugin Validation page instead.

This way everything is a bit more cleaner and also always any future expansions to the plugin validation code to be added, for example: adding custom rules to a plugin e.g. https://octobercms.com/docs/api/translator/beforeresolve

My thinking is to basically merge these things together on a Validation page in the plugin section:

e.g.

public function boot()
{
        // Register reserved keyword validation - part 1
        Event::listen('translator.beforeResolve', function ($key, $replaces, $locale) {
            if ($key === 'validation.valid_jsonable') {
                return Lang::get('acme.example::lang.validation.validJsonable');
            }
        });

        // Create and extend custom validation methods - Part 2
        Validator::extend('validJsonable', Jsonable::class);
}

Then create a rules file etc.

LukeTowers commented

Those two things are different though, the Validation service is the underlying logic that powers the Validation trait, the validation trait is essentially syntactic sugar on top of the validation service meant specifically for models.

summercms commented

@LukeTowers syntactic sugar lol.

Laravel Validation Section

image

Plugin Validation Section

image

Trait Section

image

(*) array examples added to plugin and trait section as well.

LukeTowers commented

Hmm, I think it would probably be better just to link to the validation trait page from the models page, since that's what the docs are for, not for "plugin validation"

bennothommo commented

Definitely do not agree with there being a Validation page under Plugins, validation happens everywhere - not just within plugins. I personally find the validation docs to be easy to find - Validation after all is a service, and if you recognise the models using a trait, then the Traits section is easy to find too.

While I agree that maybe a link between the pages could be made, and the content could be updated to include more recent updates to validation (such as this), I don't think the placement of the pages needs to change.

summercms commented

@LukeTowers @bennothommo

No problem understand what you both are saying. Will submit a pr just for the array codes examples.

Just going to ask (I'm sure it will be ok). I want to hard fork the doc's and write my own custom notes etc over the top and merge some October Tips into the doc's and convert it into using html language from markdown etc. Just thought I'd be transparent and say it - I'm sure you guys will be fine with it. Also at a later date need to start merging into the October II api doc's etc.

LukeTowers commented

@ayumi-cloud sounds good. FYI for your fork if you want to publicly release it you can't call it "October II". The project is MIT licensed but the name, brand, & logo belong to us.

  • 👍2