PHP/JS Form Class - Array vs OO

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.

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

Приветствия

Answer 1

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

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

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

Answer 2

Почему использовать объекты? Becouase они гораздо более сложные типы. Рассмотрим следующий пример (я никогда не useed 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); 

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