build и validate формы, средствами PHP

SergXP

Новичок
Всем привет!

Возник вопрос, имеются ли нормальные готовые решения в свободном доступе?
Попробовал несколько классов, все равно что-то не то... не понравились)
Из описаний понравилась библиотека HTML_QuickForm2, пробежался только по документации..

Но проблема остро стоит: быстродействие.
Тогда придется отказаться от этой идеи, или писать свое что-то легкое..
Конечно функционал уже будет не такой мощный, но основное что нужно сделается:
генерация формы, валидаторы, представления-декораторы(views).

еще в голове крутиться сделать так:
создаем массивы-настройки формы, т.е. указываем какая форма, список полей и их настройки...
сама форма обычный шаблон phtml.

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

Хочу услышать Ваше мнение, коллеги))
 

SergXP

Новичок
Спасибо! Но увы, боюсь не подходит. как вариант оставлю :)
Есть еще идеи?
P.S. ищу на github, sourceforge, phpclasses..
 

tz-lom

Продвинутый новичок
А чем быстродействие HTML_QuickForm2 не устроило?
 

SergXP

Новичок
его размер, в 15 раз больше, чем мой каркас-фреймворк MVC
на данный момент производительность примерно такая:
STAT: 0.49MB / 0.135774 sec
это с подключением к бд, и отправкой запроса SELECT.
без них:
STAT: 0.46MB / 0.007925 sec
на винде, без APC,eaccelerator и тп..
что будет, если я подключу HTML_QuickForm2? )))
еще не пробовал, надо проверить.. но если скачек пойдет больше 1мб и время вырастит в разы.. мне придется отказаться..
 

tz-lom

Продвинутый новичок
а сервер тоже будет на винде без APC ???
это оптимизация ненаписанного кода, не нужно так делать
 

SergXP

Новичок
не совсем понял Вас:
это оптимизация ненаписанного кода, не нужно так делать
нет, сервер будет на Debian. nginx+php+postgresql+eaccelerator+memcached

кстати, HTML_QuickForm2 кажется тоже отпадает.. затребовал еще доп библиотеку PEAR.
 

tz-lom

Продвинутый новичок
если использовать библиотеку:
- не значительно увеличится потреблене памяти и время работы
+ оно будет работать здесь и сейчас
+ можно писать баг репорты чтобы чинил кто то другой
+- не факт что починит

если не использовать библиотеку:
- не значительно увеличится потреблене памяти и время работы
- потребуется время на разработку и отладку
- потом ещё отладка не очевидных вариантов вариантов использования
- не факт что выйдет легче чем библиотека
- потрачено время
+ сделал сам

и вообще про скорость:
у тебя замедление в 19 раз из за подключения к БД, и это нормально, при равной кривизне рук РНР код работает на порядок быстрее чем БД
 

SergXP

Новичок
да вот единственное что плохо, это уйдет время на разработку(

при подключении к БД, генерация страницы взлетает на 90-100мс.. без коннекта страница грузится за 5-15 мс.
автозагрузчик работает очень быстро)

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

отдельно запустил данную библиотеку.. пример взят из папки examples
STAT: 2.27MB / 0.057205 sec
при включенном eaccelerator
STAT: 1.18MB / 0.038336 sec
плюс подключается дополнительно 40 файлов.

результат не обрадовал(
если только использовать дополнительное кеширование...
 

С.

Продвинутый новичок
Быстрый билдер форм, и чтоб генерил формы на все случаи жизни -- это утопия. Или берите одного из мастодонтов, или разрабатывайте какую-либо ограниченную концепцию UI, подвязанную под конкретную задачу. А в рамках ее можно содать очень легкий и очень быстрый билдер.
 

SergXP

Новичок
тяжеловесы отпадают сразу.
если думать логически, нужно всего три класса: генератор,валидатор,шаблонизатор.
а не 100 файлов, с запутанной архитектурой.. изначально такие библиотеки не рассчитаны на производительность..
не хочу повторять ошибки таких фреймворков как Zend
 

tz-lom

Продвинутый новичок
на правах рекламы:
У меня нет ни шаблонизатора (native PHP шаблон получается на этапе компиляции, хотя сейчас есть возможность очень малыми трудозатратами подключить какой угодно шаблонизатор если использовать NTM)
Ни генератора (вся генерация происходит во время компиляции)
Сам валидатор весьма простой и лёгковесный
P.S.
да, библиотека сырая, пока ей пользуюсь только я, собственно поэтому и предлагаю её другим, хочется получить отзывы
и я предлагаю некоторую помощь в решении проблем с ней связанных, но ничего гарантировать не могу, поэтому в конечном счёте все риски ложатся на вас, как и с любым другим кодом
 

SergXP

Новичок
а документации никакой нету?
не могу найти примеры использования.
нашел только тесты.
 

Sad Spirit

мизантроп (Старожил PHPClub)
Команда форума
тяжеловесы отпадают сразу.
если думать логически, нужно всего три класса: генератор,валидатор,шаблонизатор.
А генератор будет генерировать все элементы? А если мы захотим добавить новые? А правила в валидаторе? А зачем шаблонизатор включать, не проще использовать внешний?

Я просто смотрел некоторое кол-во формобиблиотек, естественно. При таком подходе, таки да, получается три класса по паре-тройке тыщ строк каждый. Но поддерживать это я бы не хотел.

а не 100 файлов, с запутанной архитектурой.. изначально такие библиотеки не рассчитаны на производительность..
Изначально такие библиотеки рассчитаны в основном на быстрое создание форм в админке. Туда дикие тыщи народу не ходят, а форм там, как правило, много. В принципе можно заняться оптимизацией на спичках и, например, покидать все используемые классы в один файл, удалив оттуда require_once. Либо, опять же, выкинуть require_once и использовать autoload, оно, говорят, быстрее. Плюс в QuickForm2 есть практически готовый автолоадер.
 

SergXP

Новичок
А генератор будет генерировать все элементы? А если мы захотим добавить новые? А правила в валидаторе? А зачем шаблонизатор включать, не проще использовать внешний?
Конечно все, все которые необходимы:
text
hidden
password
textarea
file
radio
checkbox
listbox
dropdownlist
checkboxlist
radiolist

Не думаю, что они будут на 3000 строк))
Генератор = принимает параметры от нашего класса(например форма авторизации), генерирует необходимый массив, передает его шаблонизатору.
Шаблонизатор = обрабатывает массив, обрабатывает декораторы, генерирует форму, результат уходит назад генератору.
Валидатор = соответственно обращается к генератору, получает по каждому элементу фильтры и валидаторы.. запускает проверку на валидность...

Как пример, наброски..

Объявляем наш класс:
PHP:
class Form_Auth extends MVC_Form {

    public function __construct() {
        $form = array(
            'name' => 'auth',
            'id' => 'auth',
            'method' => 'POST',
            'enctype' => 'multipart/form-data',
            'action' => '/login',
            'class' => 'fauth',
            'style' => null,
            'label' => 'Авторизация',
            'description' => 'Вход в личный кабинет',
            'decorator' => array(
                'form' => 'table',
                'label' => 'td',
                'row' => 'tr',
                'element' => 'td',
                'description' => 'td'
            ),
            'view' => 'auth');

        parent::__construct($form);

        $login = $this->createElement('text', array(
            'attr' => array(
                'name' => 'login',
                'id' => 'login',
                'value' => 'admin',
                'class' => 'finput',
                'style' => '',
            ),
            'label' => 'Login:',
            'description' => 'Enter you login',
            'validate' => array('Required'),
            'filter' => array('Trim'),
                ));

      // это уже рендер
      $this->addElements(array(
            $login
        ));
    }
}
В классе MVC_Form создаем метод:

PHP:
    public function addElements($forms = array()) {
        return MVC_Form_View::render($forms); 
    }
И конечно же View начинает разбирать что мы там передали:
PHP:
public function render($formы) {
        if (!is_null($forms)) {

            foreach ($forms['elements'] as $k => $v) {
                switch ($v['type']) {
                    case 'text':
                            echo 'input text';
                             Evo_Form_View::input($v);
                        break;
                    case 'password':
                            echo 'input password';
                        break;

                    default:
                        break;
                }
               
            }
        }
    }
Пока еще в общем думаю, прикидываю на бумаге)

Но в данном примере, если пользователь вызывает:
PHP:
$authform = new Form_auth(); 
echo $authform;
// либо передаю в основной шаблонизатор:
$this->view->auth = $authform;
на экран выводится сгенерированная форма)
 

Sad Spirit

мизантроп (Старожил PHPClub)
Команда форума
Конечно все, все которые необходимы:
text
hidden
password
textarea
file
radio
checkbox
listbox
dropdownlist
checkboxlist
radiolist
а когда мы решим добавить элементы из html5 или что-то обвешанное жаваскриптом по самые помидоры, мы будем писать подкласс генератора? Пнятненько...

PHP:
class Form_Auth extends MVC_Form {

    public function __construct() {
        $form = array(
            'name' => 'auth',
            'id' => 'auth',
            'method' => 'POST',
            'enctype' => 'multipart/form-data',
            'action' => '/login',
            'class' => 'fauth',
            'style' => null,
            'label' => 'Авторизация',
            'description' => 'Вход в личный кабинет',
            'decorator' => array(
                'form' => 'table',
                'label' => 'td',
                'row' => 'tr',
                'element' => 'td',
                'description' => 'td'
            ),
            'view' => 'auth');
    }
}
Т.е. в одном массиве мы держим и атрибуты тегов HTML, и настройки вывода, и прочее барахло? Пнятненько...

И конечно же View начинает разбирать что мы там передали:
PHP:
public function render($formы) {
        if (!is_null($forms)) {

            foreach ($forms['elements'] as $k => $v) {
                switch ($v['type']) {
                    case 'text':
                            echo 'input text';
                             Evo_Form_View::input($v);
                        break;
                    case 'password':
                            echo 'input password';
                        break;

                    default:
                        break;
                }
               
            }
        }
    }
А вот в этот гигантский switch мы и будем добавлять новые варианты при добавлении новых типов элементов. Удобненько...

Ну то есть стремление изобрести велосипед --- это атлична-атлична, например. Но колёса у него пока скорее даже треугольные.

Не думаю, что они будут на 3000 строк))
Не, ну пока не будут. Но вот когда доберёшься хоть до половины функциАНАЛьности больших библиотек...
 

SergXP

Новичок
:D я показал наброски.. к принцип работы..
к тому же, можно сделать цепочкой методов, наподобие зенда

PHP:
$userName =  $this->createElement('text', 'email_auth');
$userName->setLabel('Email:')
                ->setAttrib('size', 25)
                ->addValidator('StringLength', false,array(5,50))
                ->setValue('')
                ->setAttrib('class', 'field blink')
                ->setRequired(true)
                ->addFilter('StripTags')
                ->addFilter('StringTrim')
               ->addValidator('NotEmpty');
Есть стремление, найти баланс между дальнейшей скоростью разработки и производительностью.
Стоит ли делать такой класс, или лучше вручную производить верстку форм.. на проект, с планируемой посещаемостью больше 500к уникальных посетителей в сутки..
думаю стоит задуматься..
 
Сверху