PHP / JS Form Class - массив против ОО

Question

Я недавно начал работать над классом форм PHP / JS, который также будет включать построитель форм SQL (например, создание простых форм из sql и автоматические вставки / обновления).

Я пробовал несколько классов (zend_form, clonefish, PHP Form Builder Class, phorms и т. Д.), Но пока не нашел полного решения, которое было бы простым, настраиваемым и полным (как на стороне сервера, так и на стороне клиента)., охватывает все простые html-элементы и множество dhtml-элементов: сортировка, wysiwyg, загрузка файла mutli, средство выбора даты, проверка ajax и т. д.)

Мой вопрос: почему некоторые «классы» реализуют элементы через массиви другие через соответствующие вызовы класса OO.

например.Clonefish (популярный коммерческий класс php):

    $config = Array( 

  'username' => Array( 
    'type'           => 'inputText', 
    'displayname'    => 'Username', 
    validation     => Array( 
      Array(  
        'type'    => 'string', 
        'minimum' => 5, 
        'maximum' => 15, 
      ), 
    ), 
  ));

$clonefish = new clonefish( 'loginform', 'test.php', 'POST' ); 

$clonefish->addElements( $config, $_POST );

Затем другие, например.Zend_Form

$form = new Zend_Form;
$username = new Zend_Form_Element_Text('username');
$username->addValidator(new Zend_Validate_Alnum());
$form->addElement($username);

Я понимаю, что Zend_Form может передавать элементы через массив, похожий на clonefish, но зачем это делать?

Есть ли какая-то выгода?Кажется, что все усложняется, особенно при использовании надлежащей IDE, такой как Komodo.

Буду признателен за любые мысли, так как я не хочу заходить слишком далеко и осознавать, что использование массивов для добавления элементов принесло большую пользу(хотя это не будет большой задачей для добавления).

Cheers

Answer 1

Мой вопрос заключается в том, почему некоторые «классы» реализуют элементы через массив, а другие - через соответствующие вызовы классов OO.

Для удобства. Это менее многословно и менее похоже на кодирование и больше похоже на конфигурацию, и вам нужно меньше глубоких знаний API.

Кстати, причина, по которой вы еще не наткнулись на простое, настраиваемое и законченное решение, заключается в том, что оно не простое. Формы, их проверка и рендеринг сложны, особенно если вы хотите настроить их для любых целей. Компоненты формы ZF являются хорошим примером того, как правильно разделить и разделить все задачи, чтобы получить максимально расширяемый конструктор форм (включая код на стороне клиента через Zend_Dojo или ZendX_Jquery). Но они также являются отличным примером сложности, необходимой для этого. Даже с удобной конфигурацией массива чертовски трудно заставить их подчиняться вашей воле, особенно если вам нужно отойти от конфигурации по умолчанию и рендеринга.

Answer 2

Зачем использовать предметы? Потому что они гораздо более сложные типы. Рассмотрим следующий пример (я никогда не использовал Zend_Form, поэтому я даже не знаю его архитектуру):

class MySuperAlnumValidator extends Zend_Validate_Alnum {
     protected $forbiddenWords = array();

     public function addForbiddenWord($word) {
         $this->forbiddenWords[] = $word;
     } 

     // Override Zend_Value_Alnum::validate() - I don't know whether such a method even exists 
     // but you know what's the point
     public function validate() {
          parent::validate();

          if (in_array($this->value, $this->forbiddenWords) {
              throw new Exception('Invalid value.');
          }

          return $this->value;
     }
}

// -----------------------

$validator = new MySuperAlnumValidator();
$validator->addForbiddenWord('admin');
$validator->addForbiddenWord('administrator');

$username->addValidator($validator);

Это только простой пример, но когда вы начинаете писать более сложные валидаторы / поля формы / и т.д. тогда объекты в принципе являются единственным значимым инструментом.