начата разработка новой версии HTML_QuickForm

[Sad Spirit]

начата разработка новой версии HTML_QuickForm

В общем мы два года собирались и наконец приступили к написанию HTML_QuickForm2.

Что планируется:

• Пакет для PHP5 работающий с включенным E_STRICT
• Функциональность по кр. мере не меньше существующего HTML_QuickForm
• Unit тесты. Из-за их отсутствия в старом HTML_QuickForm было мно-о-ого проблем с разработкой

Принимаются feature requests на сайте PEAR
Открыта wiki по вопросам разработки пакета (для редактирования страниц надо зарегистрироваться).
Не уверенные в своём английском могут даже отметиться с предложениями в этой теме.

Ура, товарищи!

 

[magic]

Ура.

Чем помочь?

 

[itprog]

Sad Spirit

Немного не ясно, кто вы?

"Пакет для PHP5 работающий с включенным E_STRICT"
Это значит что HTML_QuickForm2 будет написан изначально под PHP5 или только обеспечивать совместимость?


ps: не мешало бы избавиться от "eval" в коде, кое-где замечал его использование.

 

[crocodile2u]

itprog
"Пакет для PHP5 работающий с включенным E_STRICT" - просто не будет работать под php4.

А вот eval, и правда, следует вычистить, имхо.

Sad Spirit
Начинание хорошее!

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

Кроме того, можно сделать ряд фабричных методов, хотя бы для создания/добавления самых часто используемых элементов (addTextInput(), addTextarea(), например). Это должно сделать интерфейс более четким.

Далее: в HTML_Common2 есть метод setAttribute() и это замечательно. (Насколько мне известно, в первой версии был только setAttributes())

 

[fixxxer]

Я так понял, что судя по планируемому использованию SPL, поддержка php4 не планируется (и правильно).

Предложения по интерфейсу куда постить? (если это интересно)

 

[crocodile2u]

fixxxer
Я лично на Wiki зарегился, написал туда пару строк

 

[Sad Spirit]

Автор оригинала: magic
Чем помочь?

Сейчас лучше всего помогать чтением wiki и оставлением там комментариев по поводу архитектуры и желаемой функциональности.

Автор оригинала: itprog
Немного не ясно, кто вы?

На данный момент "мы" --- это Bertrand Mansion и я (собственно на странице пакета написано)

ps: не мешало бы избавиться от "eval" в коде, кое-где замечал его использование.

eval()'ов в пакете не так много, используются они в основном в контексте "по имени элемента формы типа foo[bar][baz] получить его значение из массива $_GET / $_POST". Проблем с безопасностью быть не должно т.к. имена элементам вы сами раздаёте.

Эти места можно, конечно, переписать без eval()'ов, но не факт, что оно будет проще и понятней.

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

Это само собой, я сам для некоторых методов аргументы не помню.
От таких чудес как методы с 7 аргументами и разные списки аргументов в конструкторах элементов избавимся.

Кроме того, можно сделать ряд фабричных методов, хотя бы для создания/добавления самых часто используемых элементов (addTextInput(), addTextarea(), например). Это должно сделать интерфейс более четким.

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

Автор оригинала: fixxxer
Предложения по интерфейсу куда постить? (если это интересно)

В wiki. На русском сюда можно.


Пакет, как тут было правильно понято, будет работать только под PHP5: особого смысла начинать щас проект под PHP4 нет, особенно учитывая, что планируется новая версия, несовместимая со старым QuickForm. Старый, кстати, под PHP5 замечательно работает.

 

[crocodile2u]

Насчет addTextInput(), addTextarea(). Расскажу подробнее. Мотивация здесь в том, чтобы сделать более четко определенным возвращаемый объект. addElement() может возвращать лишь HTML_QuickForm_element - тогда как конкретная фабрика может вернуть конкретный объект, допустим, HTML_QuickForm_text. Это облегчит работу с самим объектом - фактически, появится формальное право использовать "добавочные" методы, определенные в конкретном классе. А кроме того, это облегчит работу в IDE - обсепечит подсказки на методы конкретных классов.

Далее, насчет нового элемента RADIOS. Я считаю, что на самом деле нужен более радикальный подход. Сделать один элемент SELECT, который в зависимости от значений свойств multiple и display (??? - обсудим - ???) - может отрендерить себя как dropdown-box, как список radio-buttons или как список checkbox'ов.
Мотивация: на самом деле все эти вещи - представление одной и той же логической сущности - список вариантов для выбора. И еще: если понадобится изменить вариант показа (допустим, у нас стало слишком много радибатонов) - нужно будет лишь изменить значение свойства display.
Кстати, XForms именно подобный подход принимает.

 

[Sad Spirit]

Автор оригинала: crocodile2u
Насчет addTextInput(), addTextarea(). Расскажу подробнее. Мотивация здесь в том, чтобы сделать более четко определенным возвращаемый объект. addElement() может возвращать лишь HTML_QuickForm_element - тогда как конкретная фабрика может вернуть конкретный объект, допустим, HTML_QuickForm_text. Это облегчит работу с самим объектом - фактически, появится формальное право использовать "добавочные" методы, определенные в конкретном классе. А кроме того, это облегчит работу в IDE - обсепечит подсказки на методы конкретных классов.

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

Далее, насчет нового элемента RADIOS. Я считаю, что на самом деле нужен более радикальный подход. Сделать один элемент SELECT, который в зависимости от значений свойств multiple и display (??? - обсудим - ???) - может отрендерить себя как dropdown-box, как список radio-buttons или как список checkbox'ов.
Мотивация: на самом деле все эти вещи - представление одной и той же логической сущности - список вариантов для выбора. И еще: если понадобится изменить вариант показа (допустим, у нас стало слишком много радибатонов) - нужно будет лишь изменить значение свойства display.
Кстати, XForms именно подобный подход принимает.

RADIOS --- это не моя идея, а Bertrand'а, так что лучше про неё в wiki писать, этот форум он не читает (а если и читает, то нихрена не понимает ).

Идея, в принципе, весьма и весьма интересная (XForms опять же не дураки придумывали). Но я думаю, тут скорее нада придумать общий интерфейц для таких элементов, нежели пытаться засунуть всё в один класс. Чтобы, грубо говоря, достаточно было в коде заменить название элемента и наслаждаться результатом.

Да, и при этом ещё надо поддерживать optroup'ы и их "отображения" на списки чекбоксов / радиокнопок.

 

[crocodile2u]

Sad Spirit

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

Ну, мне, собсно, гораздо важнее чистота подхода. IDE - это лишь приятное следствие.

Рассмотрим простой случай:

$element = $form->addElement('select',..);
$element->addOption(...);

При этом по спецификации HTML_QuickForm::addElement() возвращает нам вовсе не HTML_QuickForm_select, а HTML_QuickForm_element. А метод addOption() есть только у HTML_QuickForm_select. Таким образом, мы вынуждены использовать метод, которого использовать не должны.

Вот поэтому и было бы хорошо использовать ряд фабричных методов. Тогда HTML_QuickForm::addSelect() по спецификации возвращал бы именно HTML_QuickForm_select.

Плюс - я, собственно, не понимаю, чем так уж плохи 23 метода, каждый в одну строку... (Тем более, что я лично насчитал всего 17, исключив абстрактный HTML_QuickForm_element и те классы, которые планируется вроде бы переместить в свои отдельные пакеты)

ЗЫ: В Wiki я уже написал про RADIOS.