are we doing everywhere the https:// and not the git@github.com? just curious

Using git@github.com requires setting up SSH for your account, which does not provide any value when accessing public reposiitories in a read-only way (it used to be reserved to collaborators btw, but I think this has changed)

yeah and it is far a better practice to get people into contributing and learning. We shouldn't assume all are read-only people 👶

the component repos are read-only, so it's only for read-only people. And if you want to contribute, you look into the contributing docs and not this docs

And the https url is not a read-only URL either (and anyway, even contributors should not push to the symfony repo directly but to their fork, as everything goes through PRs even for the core team)

I would say "do easy validation tasks with it"... Don´t you think the sentence is a bit weird right now?

Shouldn´t it be validate that a string...?

would be good to put an example that fails to show some more detail on the output

The string is 8 characters long, while the constraints expects a minimum of 10 character. So it already fails. However, I agree that we should put some "show error" logic in here (I copied this example from the README).

actually, it's already in there....

is recommended to use

could you please provide a tip saying how it is done in symfony or maybe the service factory is shared but each time it creates a validator or how it is done, would be a good complement.

maybe let's also mention what the deps that configure a validator are:

    public function __construct(
        MetadataFactoryInterface $metadataFactory,
        ConstraintValidatorFactoryInterface $validatorFactory,
        TranslatorInterface $translator,
        $translationDomain = 'validators',
        array $objectInitializers = array()
    )

arrays instead of array

To do that is said twice... I am not native but what about something like "In order to achieve that"

better than ... is to add a simple example

as you don't know what it does, I don't think it's valuable at this point.

A better name would be Mapping Constraints rather than Loading Resources IMO. The goal of this process is to map the constraints on your code, not to load some resources.

Resources are loaded to know the constraints, not the opposite. Loading Resources is a primary goal for the Config component, not for the Validator component.

I had a discussion about this myself too :)

I want to have a clear split in the documention:

• Defining constraints for classes
• Using loaders to load the definitions
• Using the validator methods to validate classes using the loaded definitions

I think "Mapping Constraints" covers part 1 and 2, so it is not a clear split. "Loading Resources", on its way is maybe too specific.

agree with @wouterj it makes sense, i guess he still needs to complete the PR to see the second part more clearly

The metadata can also be passed to the validate methods

not when validating a class

should -> can

well, it should be defined in a configuration file or the object isn't validated :)

maybe let's go with the example of the min length and display what is inside the config/validation.yml in terms of this example, i think it should help readers a lot to get up to following the documentation with this example.

that'll be in the next chapter (as said in the intro...)

maybe let's add a note that it works together with the reader and the loader just loads the annotations but does not read them, for that it needs that collaborator

why protected? is this how all examples are provided in the documentation? just curious since i recently saw a note on changing visibility in other parts

I always use protected when writing the documentation. We might create a normalization PR to fix that though :)

it will give an error if the dependency is not required explicitly as it is a suggested dependency when used standalone https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Validator/composer.json#L28

so maybe let's add a note that this must be specified in their project root composer.json , oh sorry just saw the thing below, nevermind 👶

This sentence sounds weird to me, I would say you should have xxx and yyy packages installed from Packagist, but again I am not native :)

Hmm, I'm not a native either, but the current thing sounds better to me. What's the correct way @weaverryan ? :)

i wonder if the autoload.php for some projects is still needed to load the annotation reader, or if any comment should be made here, just to ensure or avoid some pitfalls for not being able to make it work.

good idea!

should just be cache and no cacher but i give you the reasons sometimes the classes are not named Cacher

problems -> problem

it's still a cacher. We don't talk about the name here, just what it does.

My name is Wouter, yet I'm still a person... In the same way, something called YamlFile can be a cacher.

And using "cache" here seems like we configure the cache system behind it, strictly spoken we configure the adapter.

cachers by implementing :class...

This means instead of that means?

What about the doctrine cache, is that by default? what is it used for and the differences between it and the apc cache.

doctrinecache is integrated in Symfony 2.5 (see also the PR description)