есть ли минусы в использовании PEAR HTML_QuickForm ?

[que_bunt]

есть ли минусы в использовании PEAR HTML_QuickForm ?

Здраствуйте!

решил использовать в своих проектах PEAR HTML_QuickForm.
посмотрел мануал, статейки всякие, сделал вывод что QuickForm хорошое решение.

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

оставьте пожалуста свои отзывы о QuickForm.

-~{}~ 30.09.06 16:34:
и ещо один практичный вопрос:
можно ли например с помощью QuickForm сделать значение с переменным числом полей.
тоесть например есть каталог с верстатами, у каждого верстата много _разных_ характеристик.
делаем поля:

<input type='text' name='tth[name][]' size=20>
<input type='text' name='tth[value][]' size=30 maxlength=100><br>
<input type="button" value="добавить поле" onClick="AddItem()" ID="add" >

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

возможно ли как-то сделать (интегрировать) в QuickForm такую задачу?
буду благодарин за ответы.

-~{}~ 02.10.06 10:47:

может хоть кто-то, а?

 

[Яро]

Напиши свой класс элемента формы для такой задачи.

 

[que_bunt]

Яро спасибо за ответ.
а вообще о QuickForm что скажешь?
используешь в своих разработках?

 

[Яро]

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

 

[SmokyPython]

Скажу свое IMHO почему я решил не использовать HTML_QuickForm(особо с этим проектом не работал сразу бросились в глаза некоторые минусы и забил на него)
Вобщем вот:
-существуют некоторые проблемы с встраиванием в дизайн
-'своеобразная' архитектура, на мой взгляд очень... эээ... не запоминающаяся, думаю здесь уместно было бы сделать через события как в Delphi(TForm), а так слишком много конструкций которых я стараюсь избегать, хотя это вопрос религии, но для меня он был основным
-валидация данных сильно встроена в проект
-если даже делать все с нуля времени это занимает не много вполне сопастовимо думаю, если делать через HTML_QuickForm. И валидатор нормальный будет. И знать будешь узкие места для последующей автоматизации. И проблем не будет с обрабатыванием твоей конструкции...

 

[Sad Spirit]

Автор оригинала: SmokyPython
-существуют некоторые проблемы с встраиванием в дизайн

Какие именно проблемы?

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

Принципиальную разницу между Delphi и web-приложением объяснять надо?

Какие именно конструкции не нравятся?

-валидация данных сильно встроена в проект

Можно вот тут поподробнее?

-если даже делать все с нуля времени это занимает не много вполне сопастовимо думаю, если делать через HTML_QuickForm. И валидатор нормальный будет. И знать будешь узкие места для последующей автоматизации. И проблем не будет с обрабатыванием твоей конструкции...

И не надо сказок. Написать пакеты для работы с формами, завязанный на твой Framework / шаблонизатор / прочую шнягу --- дело недолгое. А вот написать такой, чтобы был достаточно независим от всего этого...

P.S. Вопросы, кстати, задаются не с целью докопаться, а с целью выяснить, что можно изменить в пишущемся HTML_QuickForm2.

 

[Frutik]

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

Автор оригинала: Sad Spirit
P.S. Вопросы, кстати, задаются не с целью докопаться, а с целью выяснить, что можно изменить в пишущемся HTML_QuickForm2.

по ходу вопрос. алексей, это просто порт с учетом особенностей использования на платформе php5 или чтото более фундаментальное (в архитектуре, апи)?

когда непосредственно у элементов появится, например, такой напрашивающийся метод как addRule() ? %)

куда более естественно выглядит код

$element->addRule('required', 'required');

вместо

$form->($element->getName(),'required', 'required');

 

[que_bunt]

спасибо всем за присоединение к дискусии.

Sad Spirit
когда приблизительно планируеться релиз HTML_QuickForm2 ?
и сильно ли по интерфейсу он будет отличаться от обычного QuickForm ?

 

[Sad Spirit]

Автор оригинала: Frutik
по ходу вопрос. алексей, это просто порт с учетом особенностей использования на платформе php5 или чтото более фундаментальное (в архитектуре, апи)?

Нечто более фундаментальное, мы особо не будем заморачиваться обратной совместимостью.
Вместо групп, например, планируются более общие "контейнеры", которые могут быть также и вложеннымми, с API на базе DOM.

когда непосредственно у элементов появится, например, такой напрашивающийся метод как addRule() ? %)

куда более естественно выглядит код

$element->addRule('required', 'required');

вместо

$form->($element->getName(),'required', 'required');

Угу, скорее всего всё именно так и будет. Но до написания валидации ещё далеко-о-о.

Автор оригинала: que_bunt
когда приблизительно планируеться релиз HTML_QuickForm2 ?

Не знаю пока --- оба разработчика люди занятые, работаем над пакетом как время будет.
За процессом можно следить в wiki и заглядывать в CVS.

и сильно ли по интерфейсу он будет отличаться от обычного QuickForm ?

Сильно. Но там скорее всего будет поменьше методов и их будет попроще запомнить, уродств типа разных наборов параметров у конструкторов разных элементов и методов, принимающих по 7 параметров, не будет

 

[que_bunt]

Сильно. Но там скорее всего будет поменьше методов и их будет попроще запомнить, уродств типа разных наборов параметров у конструкторов разных элементов и методов, принимающих по 7 параметров, не будет

это очень радует. будем ждать.

 

[Frutik]

Автор оригинала: que_bunt
это очень радует. будем ждать.

зачем ждать. можна пока юзать и то что есть. даже в таком виде это один из самых энтерпрайс-реди пакетов в пеаре

 

[que_bunt]

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

 

[SmokyPython]

Sad Spirit

И не надо сказок. ... от всего этого...

Я вообще-то тоже самое имел ввиду. И в свое время тоже задался этим вопросом чего лучше использовать QuickForm или чего-нибудь еще, оказалось что написать свое будет быстрее/красивее чем приспосабливать QuickForm.
А проболеммы возникли при прикручивании к базе данных, в том виде что предполагается в QuickForm это очень не удобно ибо при отделении скул запросов от всего остального приходилось много менять если чего изменялось(а меняется очень много, низнаю от команды это зависит или еще от чего. То одну картинку надо вставлять то три или вообще переделать на бесконечное кол-во и тд) и путем наследования тоже неудобно тк практически все дописывать нужно.

валидация данных сильно встроена в проект

Со всеми AddRule AddFilter, мне особо непонятно, зачем это надо, прямой им конкурент непосредственно чистый php куда можно прикрутить любой валидатор и сделать любые проверки, те моменты которые скрываются путем ввода этих методов на мой взгляд того не стоят. И универсальность страдает

существуют некоторые проблемы с встраиванием в дизайн

Вот как я понял ты используешь XSLT и как это будет с точки зрения QuickForm?
quote]Принципиальную разницу между Delphi и web-приложением объяснять надо?[[/QUOTE]
Думаю ты не понял у меня так
$form = new MyForm();
$form->Run();
все остальное в классах в onCreate onValidate, мне удобнее так ничего с этим не поделаешь. А ваще объясни в чем же принципиальная разница.

Вопросы, кстати, задаются не с целью докопаться, а с целью выяснить, что можно изменить в пишущемся HTML_QuickForm2

Могу наверно в пятницу сказать/показать чего бы хотелось чтобы мне увидеть от подобного проекта

 

[Frutik]

это обработчик форм. при чем тут скул запросы? форма валидна - едем дальше нет идем по кругу...

скажи/покажи. возможно этого захотят и другие

 

[Sad Spirit]

Автор оригинала: SmokyPython
А проболеммы возникли при прикручивании к базе данных, в том виде что предполагается в QuickForm это очень не удобно ибо при отделении скул запросов от всего остального приходилось много менять если чего изменялось(а меняется очень много, низнаю от команды это зависит или еще от чего. То одну картинку надо вставлять то три или вообще переделать на бесконечное кол-во и тд) и путем наследования тоже неудобно тк практически все дописывать нужно.

Как уже отметили, база данных тут вообще не при делах.

Со всеми AddRule AddFilter, мне особо непонятно, зачем это надо, прямой им конкурент непосредственно чистый php куда можно прикрутить любой валидатор и сделать любые проверки, те моменты которые скрываются путем ввода этих методов на мой взгляд того не стоят. И универсальность страдает

Вообще-то как минимум одну причину я тебе назову: автоматическая генерация javascript'а для валидации. Да и возможность воткнуть свою функцию для проверки никто не отнимал.

Вот как я понял ты используешь XSLT и как это будет с точки зрения QuickForm?

XSLT я пока особо не использую, а с точки зрения QuickForm это будет обычно: генерим промежуточный XML посредством любого Renderer'а, потом накладываем XSLT-преобразование. QuickForm генерит well-formed код, так что проблем быть не должно.

Думаю ты не понял у меня так
$form = new MyForm();
$form->Run();
все остальное в классах в onCreate onValidate, мне удобнее так ничего с этим не поделаешь. А ваще объясни в чем же принципиальная разница.

Если тебе для полного щастья нехватает метода run(), то он есть в пакете HTML_QuickForm_Controller
А принципиальная разница в том, что када ты жмёшь кнопку в Delphi приложении, при этом не отправляется запрос на сервер.