JeroenDeDauw / ParamProcessor

Declarative parameter processing library
https://entropywins.wtf
Other
20 stars 4 forks source link

How to know which param caused an error? #31

Open osnard opened 6 years ago

osnard commented 6 years ago

In Processor::processOneParam, if the processed IParam has errors, those errors are being added to the indexed Processor::$errors array. The list of errors can be accessed after processing by Processor::getErrors method.

Unfortunately the information which parameter caused the error is lost. Or am I missing something?

I think this could easily be changed by using the parameter name as an index in Processor::$errors array. If desired, I could provide a patch.

JeroenDeDauw commented 6 years ago

The name of the parameter is recorded: https://github.com/JeroenDeDauw/ParamProcessor/blob/master/src/Processor.php#L251

Is that not enough?

osnard commented 6 years ago

Hmm... I did not see the name while debugging. Maybe I missed it. Thanks for the hint. I'll doublecheck.

osnard commented 6 years ago

Well, $this->options is specific to the Processor-object and not to a single Param/ParamDefinition. So I could work around this by creating one Processor-object for each parameter I want to check.

JeroenDeDauw commented 6 years ago

That seems rather hacky. The recorded parameter name did not help?

osnard commented 6 years ago

No, unfortunately not :(. As explained in my previous comment, $this->options belongs to the Processor object, not to the Param. The name is being set when the Processor gets instantiated. To have the appropriate parameter name the Processor.php:370 [1] would need to be changed to

foreach ( $param->getErrors() as $error ) {
    $error->element = $param->getName();
    $this->errors[] = $error;
    ProcessingErrorHandler::addError( $error );
}

[1] https://github.com/JeroenDeDauw/ParamProcessor/blob/master/src/Processor.php#L370

JeroenDeDauw commented 6 years ago

Oh right, I misunderstood your earlier comment.

I saw in the message of one of the linked commits that you are creating some decoupling stuff. Without having looked at what you actually did: this sounds like a good idea. If you want to add the needed info to this library directory or create a facade that provides a better interface to consumers, such contributions are welcome.

A few years ago I was cleaning up this library a bit and got so frustrated with the poor code that I started with a re-implementation https://github.com/JeroenDeDauw/ParameterProcessor. Which made me realize that creating the functionality this library provides actually takes quite a bit of work, causing me to abandon that effort. Maybe it serves as some inspiration though.