View Issue Details

IDProjectCategoryView StatusLast Update
0000138Adventure PHP FrameworkCode-Verbesserung // Code improvementpublic2015-10-12 12:19
ReporterChristianAchatzAssigned ToChristianAchatz 
PrioritynormalSeveritytweakReproducibilityN/A
Status closedResolutionfixed 
Product Version2.0 
Target Version3.0Fixed in Version3.0 
Summary0000138: Create PHP Unit Tests for form validators and filters to document and proof functionality better
DescriptionAt present, form filters and validators are partially documented (see http://adventure-php-framework.org/Seite/113-Formulare#Chapter-5-1-11-FloatFilter for instance). Unfortunately, there are several things that might not be well specified - see discussion under http://forum.adventure-php-framework.org/viewtopic.php?f=4&t=5376 as example.

For this reason, please create PHP Unit Tests for all form filters and validators to proof correct functionality as well as to create a better documentation of the detail functionality.
TagsNo tags attached.
Codereferenz: ([Datei]:[Zeile])
Namespacetools

Relationships

related to 0000137 closedChristianAchatz Änderung für calc-example + änderung von FloatFilter 

Activities

ChristianAchatz

2014-02-06 23:05

administrator   ~0000204

Last edited: 2014-02-06 23:08

View 2 revisions

In addition to create Unit Tests refactoring of existing filters can be considered to be able to re-use validators throughout the software without being bound to use form validators.

Idea:
=====

namespace APF\tools\validation;

interface Validator {

   /**
    * @param mixed $subject The subject to validate.
    * @return bool True in case the applied argument is valid, false otherwise.
    */
   public function validate($subject);

}


namespace APF\tools\validation\validators;

use APF\tools\validation\Validator;

class TextLengthValidator implements Validator {

   const MODE_LAX = 'lax';
   const MODE_STRICT = 'strict';

   private $minLength;
   private $maxLength;
   private $mode = self::MODE_LAX;

   public function __construct($minLength, $maxLength, $mode = self::MODE_LAX) {
      $this->minLength = $minLength;
      $this->maxLength = $maxLength;
      $this->mode = $mode;
   }

   public function validate($subject) {

      // mode strict needs trim() on $input
      if ($this->mode === self::MODE_STRICT) {
         $subject = trim($subject);
      }

      // the maxlength being null, the text may contain an infinite number of characters
      if ($this->maxLength === 0) {
         if (!empty($subject) && strlen($subject) >= $this->minLength) {
            return true;
         }
      } else {
         if (!empty($subject) && strlen($subject) >= $this->minLength && strlen($subject) <= $this->maxLength) {
            return true;
         }
      }
      return false;
   }

}


namespace APF\tools\form\validator;

use APF\tools\validation\validators\TextLengthValidator as TextLengthValidatorImplementation;

class TextLengthValidator extends TextFieldValidator {

   ...

   public function validate($input) {
      $validator = new TextLengthValidatorImplementation($this->getMinLength(), $this->getMaxLength(), $this->getMode());
      return $validator->validate($input);
   }

   ...

}

dingsda

2014-02-10 13:46

developer   ~0000217

Unit Tests verstehe ich zwar immer noch nicht. aber ich poste hier mal wie von dr.e. gewünscht trotzdem den teil aus meinem forumpost zum FloatFilter:

an sich würde der FloatFilter genau den selben zweck mit und ohne das floatval() erfüllen. zumindest, wenn die usereingabe korrekt ist. also ein "3,4" würde zu "3.4" werden. für php ist der typ einer variable ja eh egal.
die nutzung von floatval erfüllt hier nicht wirklich einen zweck.
floatval ändert nur etwas am ergebnis von FloatFilter wenn die usereingabe auch nicht numerische zeichen enthält. aber dann auch nicht wirklich immer so wie man es vielleicht wünscht.
floatval("4.3 äpfel") ==> 3.4
floatval("ich habe 3.4 äpfel) ==> 0
im ersten fall würde der FloatFilter durch floatval tatsächlich einen gewinn haben. im zweiten fall ist es gar kein FloatFilter, obwohl man das vielleicht vom namen her fast erwarten könnte.

ChristianAchatz

2014-05-06 15:19

administrator   ~0000326

Postponed to 2.2 to get 2.1 closed soon.

ChristianAchatz

2014-08-23 23:18

administrator   ~0000488

Implementation done, Unit Tests outstanding.

ChristianAchatz

2014-08-30 22:35

administrator   ~0000489

Unit tests and documentation done.

Issue History

Date Modified Username Field Change
2014-02-04 21:42 ChristianAchatz New Issue
2014-02-04 21:52 ChristianAchatz Relationship added related to 0000137
2014-02-06 23:05 ChristianAchatz Note Added: 0000204
2014-02-06 23:08 ChristianAchatz Note Edited: 0000204 View Revisions
2014-02-10 13:46 dingsda Note Added: 0000217
2014-05-06 15:19 ChristianAchatz Note Added: 0000326
2014-05-06 15:19 ChristianAchatz Target Version 2.1 => 3.0
2014-08-23 22:16 ChristianAchatz Assigned To => ChristianAchatz
2014-08-23 22:16 ChristianAchatz Status new => assigned
2014-08-23 23:18 ChristianAchatz Note Added: 0000488
2014-08-30 22:35 ChristianAchatz Note Added: 0000489
2014-08-30 22:35 ChristianAchatz Status assigned => resolved
2014-08-30 22:35 ChristianAchatz Fixed in Version => 3.0
2014-08-30 22:35 ChristianAchatz Resolution open => fixed
2015-10-12 12:19 ChristianAchatz Status resolved => closed