fxposter (00:19:08 20/04/2008)
я немного о другом

fxposter (00:19:20 20/04/2008)
ты используешь отдельные классы ZF в CI

fxposter (00:19:32 20/04/2008)
у тебя основная логика - на CI

fxposter (00:19:36 20/04/2008)
а мне она не нравиться

mihailt (00:19:47 20/04/2008)
а чем?

fxposter (00:20:07 20/04/2008)
основная логика у ZF классная - Controller - просто зашибись и View’хи очень хорошие

fxposter (00:20:48 20/04/2008)
но вот чтобы это всё скомпоновать (ZF) до уровня скомпонованности всего в симфе - нужно потратить прилично времени.

fxposter (00:21:22 20/04/2008)
я тебе, кстати, могу сказать еще кое-что насчет CI

mihailt (00:21:28 20/04/2008)
м?

fxposter (00:21:34 20/04/2008)
вот ты используешь ZF с CI

fxposter (00:21:39 20/04/2008)
потому что “удобно”

mihailt (00:21:48 20/04/2008)
угу

fxposter (00:21:55 20/04/2008)
использовать CI в дополнении к ZF ты бы не стал

fxposter (00:21:59 20/04/2008)
потому что - фигня :)

mihailt (00:22:12 20/04/2008)
хех

fxposter (00:22:23 20/04/2008)
ну не то, чтобы фигня

fxposter (00:22:30 20/04/2008)
просто - не то

mihailt (00:22:38 20/04/2008)
хелперы бы скорее всего стал бы

fxposter (00:22:48 20/04/2008)
какие ?)

fxposter (00:23:34 20/04/2008)
я, кстати, в ZF недавно просматривал View Helper’ы

mihailt (00:23:34 20/04/2008)
да многие тот же form мне цишний больше нравится

fxposter (00:23:46 20/04/2008)
формы в ZF такие же

fxposter (00:23:53 20/04/2008)
как и в симфе 1.0 и CI

fxposter (00:24:04 20/04/2008)
только они уже почти deprecated :)

fxposter (00:24:19 20/04/2008)
т.е. до появления Zend_Form такие хелперы там были

fxposter (00:24:23 20/04/2008)
и пока еще есть

fxposter (00:24:52 20/04/2008)
мне вот понравилось, что добавили
partial partialLoop и action хелперы

fxposter (00:24:56 20/04/2008)
в ZF

mihailt (00:25:15 20/04/2008)
ну нифига не удобно мне кучу параметров в масиве передавать, удобней просто вызвать элемент формы и описать его

fxposter (00:25:36 20/04/2008)
каких параметров?

fxposter (00:25:39 20/04/2008)
а

fxposter (00:25:46 20/04/2008)
так тебе и не нужно :)

fxposter (00:25:52 20/04/2008)
ты описываешь форму

fxposter (00:25:55 20/04/2008)
как угодно

fxposter (00:26:03 20/04/2008)
в том же ini-файле можно :)

fxposter (00:26:52 20/04/2008)
а потом пишешь
$this->view->form = new MyForm();
а во вьюхе:
echo $this->form;

mihailt (00:26:53 20/04/2008)
нее

mihailt (00:27:08 20/04/2008)
вот именно это мне и не нравится

fxposter (00:27:12 20/04/2008)
почему?

mihailt (00:27:20 20/04/2008)
напоминает работу с XML

fxposter (00:27:29 20/04/2008)
знаешь, чем это лучше

fxposter (00:27:30 20/04/2008)
?

fxposter (00:27:41 20/04/2008)
тем, что у тебя НИЧЕГО не дублируется

fxposter (00:27:49 20/04/2008)
что ОЧЕНЬ хорошо по умолчанию

fxposter (00:28:10 20/04/2008)
и что всё, что относится к данной форме описывается в одном месте

fxposter (00:28:16 20/04/2008)
а не в нескольких

fxposter (00:28:33 20/04/2008)
это - очень хорошо

mihailt (00:29:17 20/04/2008)
ну хз мне форму рассматривать как объект почему-то не очень нравится

fxposter (00:29:29 20/04/2008)
лучше привыкай сейчас :)

fxposter (00:29:36 20/04/2008)
или старайся привыкнуть

fxposter (00:29:58 20/04/2008)
потому что такие системы очень помогают

fxposter (00:30:08 20/04/2008)
и помогают отвлечься от рутины

fxposter (00:30:15 20/04/2008)
от проверки валидности

fxposter (00:30:17 20/04/2008)
и прочего

fxposter (00:31:18 20/04/2008)
получается, что у тебя вместо этих доставших input-хелперов - формы строятся как единый обьект

fxposter (00:31:53 20/04/2008)
все уже привыкли к фразе

fxposter (00:31:59 20/04/2008)
“оно само себя рисует”

fxposter (00:32:05 20/04/2008)
в ООП

fxposter (00:32:29 20/04/2008)
только не все понимают, что это можно распространить на очень многое

fxposter (00:32:40 20/04/2008)
опиши форму - и дай ей сделать остальное за тебя

fxposter (00:32:50 20/04/2008)
пропадет куча рутинной работы

mihailt (00:33:00 20/04/2008)
типа кодегенерация

fxposter (00:33:03 20/04/2008)
нет

fxposter (00:33:14 20/04/2008)
кодогенерация - это то, что ты input’ами пишешь

fxposter (00:33:15 20/04/2008)
:)

fxposter (00:33:19 20/04/2008)
только вручную

fxposter (00:33:28 20/04/2008)
а тут оно просто “себя рисует”

mihailt (00:33:41 20/04/2008)
ну сказать та что рисовать надо

fxposter (00:33:41 20/04/2008)
когда ты на десктопе создаешь формочку

fxposter (00:33:46 20/04/2008)
это кодогенерация?

fxposter (00:33:47 20/04/2008)
:)

fxposter (00:33:52 20/04/2008)
нет

mihailt (00:34:03 20/04/2008)
да

fxposter (00:34:04 20/04/2008)
это выполнение отрисовки в рантайме

mihailt (00:34:14 20/04/2008)
хмм

fxposter (00:34:20 20/04/2008)
вот с формами так же

fxposter (00:34:29 20/04/2008)
т.е. - оно генерит HTML

fxposter (00:34:37 20/04/2008)
но, подумай, - HTML

fxposter (00:34:37 20/04/2008)
!

fxposter (00:34:43 20/04/2008)
не php-код

fxposter (00:34:45 20/04/2008)
ничего

fxposter (00:34:54 20/04/2008)
оно ничего не eval’ит

fxposter (00:35:03 20/04/2008)
оно выдает просто строку результата

mihailt (00:35:15 20/04/2008)
хмм

fxposter (00:35:24 20/04/2008)
хотя на самом деле - на это можно смотреть по разному :)

fxposter (00:35:58 20/04/2008)
но в любом случае - это не обычная статическая генерация кода

mihailt (00:36:03 20/04/2008)
озадачил ты меня

fxposter (00:36:04 20/04/2008)
это всё происходит в динамике

fxposter (00:36:11 20/04/2008)
и это в рантайме можно менять

fxposter (00:36:18 20/04/2008)
правда, к этому всему нужно привыкнуть

fxposter (00:36:34 20/04/2008)
и для этого - использовать что-то типа Zend_Form

mihailt (00:36:44 20/04/2008)
то есть больше нефига не скриптовый язык

fxposter (00:37:00 20/04/2008)
если честно, я сталкивался с мыслью, что что-то подобное должно быть

fxposter (00:37:05 20/04/2008)
когда делал много форм

fxposter (00:37:22 20/04/2008)
но именно ZF открым мне глаза на то, как это можно красиво сделать :)

fxposter (00:37:52 20/04/2008)
вообще я под генерацией кода понимаю - генерируем что-то статически

fxposter (00:38:13 20/04/2008)
и это потом используем отдельно

fxposter (00:38:24 20/04/2008)
как в симфе - сделать CRUD для таблицы

mihailt (00:38:39 20/04/2008)
ты програмист-прагматик читал?

fxposter (00:38:39 20/04/2008)
оно накидает html и php-файлов - и вот и кодогенерация

fxposter (00:38:41 20/04/2008)
нет

fxposter (00:39:00 20/04/2008)
но собирался

mihailt (00:39:03 20/04/2008)
так вот так кодегенерация описывалась по другому

mihailt (00:39:14 20/04/2008)
почитай кстати интересная штука

fxposter (00:39:37 20/04/2008)
это одна из самых советуемых книжек на programmingbooks раньше было

fxposter (00:39:39 20/04/2008)
была

mihailt (00:40:30 20/04/2008)
там люди для того чтобы не писать много однообразных программ написали программу которая принимала параматры и выдавала нужный код

fxposter (00:40:39 20/04/2008)
угу

mihailt (00:41:04 20/04/2008)
блин

mihailt (00:41:18 20/04/2008)
не могу объяснит у меня получается тоже что ты написал

fxposter (00:41:35 20/04/2008)
но тогда можно считать, что если Zend_Form делает кодогенерацию, то такую же кодогенерацию делает любая функция, которая что-то возвращает :)

mihailt (00:41:50 20/04/2008)
во

mihailt (00:41:53 20/04/2008)
ты понял

fxposter (00:42:02 20/04/2008)
я бы сказал так:

mihailt (00:42:05 20/04/2008)
только не что-то

mihailt (00:42:12 20/04/2008)
а код

fxposter (00:42:14 20/04/2008)
нет

fxposter (00:42:16 20/04/2008)
смотри

fxposter (00:42:34 20/04/2008)
кодогенерация - это когда мы генерируем код на том же уровне, на котором был написан изначальный

fxposter (00:43:06 20/04/2008)
ну или как-то так

mihailt (00:43:12 20/04/2008)
ну типо того

fxposter (00:43:24 20/04/2008)
а то получается, что
echo “<html>…”;
это тоже кодогенерация

mihailt (00:43:44 20/04/2008)
неее

fxposter (00:43:47 20/04/2008)
ага ;)

fxposter (00:44:06 20/04/2008)

echo “<html>…”;

это выражение генерирует html-код

fxposter (00:44:12 20/04/2008)
как и Zend_Form

mihailt (00:45:01 20/04/2008)
нее ну в принципе круто, только почему то все равно не цепляет

mihailt (00:45:05 20/04/2008)
но хз

fxposter (00:45:07 20/04/2008)
:-D

fxposter (00:45:09 20/04/2008)
:)

mihailt (00:45:14 20/04/2008)
может я передумаю

fxposter (00:45:23 20/04/2008)
писец, вот это у нас матёро пошел разговор

mihailt (00:45:24 20/04/2008)
говорю озадачил ты меня

mihailt (00:45:31 20/04/2008)
да конкретно так

mihailt (00:45:42 20/04/2008)
по гиковски

fxposter (00:45:48 20/04/2008)
просто суть в чем

fxposter (00:45:57 20/04/2008)
есть неправильный код

fxposter (00:46:05 20/04/2008)
там много характеристик

fxposter (00:46:59 20/04/2008)
но две из них:
1. дублирование
2. решение одной задачи во многих местах - расплылось решение по разным классам/функциям/файлам

fxposter (00:47:17 20/04/2008)
вот оба эти недостатка в себе сочетает подход с input’ами

fxposter (00:47:26 20/04/2008)
и устраняется form-обьектами

fxposter (00:48:03 20/04/2008)
кстати

fxposter (00:48:06 20/04/2008)
!!!

fxposter (00:48:10 20/04/2008)
офигенный аналог

fxposter (00:48:18 20/04/2008)
источник данных

fxposter (00:48:23 20/04/2008)
ORM!

fxposter (00:48:31 20/04/2008)
ну, или wrapper таблицы

fxposter (00:48:35 20/04/2008)
или как в CI

fxposter (00:48:38 20/04/2008)
непринципиально

mihailt (00:48:51 20/04/2008)
ну,

fxposter (00:48:53 20/04/2008)
вместо того, чтобы писать в разных местах селекты

fxposter (00:48:55 20/04/2008)
и прочее

fxposter (00:49:06 20/04/2008)
мы инкапсулируем это всё в одном обьекте

mihailt (00:49:11 20/04/2008)
так

fxposter (00:49:13 20/04/2008)
и работаем уже с ним

fxposter (00:49:21 20/04/2008)
предварительно его настроив

fxposter (00:49:33 20/04/2008)
указав имя таблицы, поля и т.д.

fxposter (00:49:40 20/04/2008)
вот с формами - ТО ЖЕ САМОЕ

fxposter (00:49:41 20/04/2008)
пипец

fxposter (00:49:44 20/04/2008)
1 в 1 почти

mihailt (00:50:12 20/04/2008)
забавно

mihailt (00:51:02 20/04/2008)
н в принципе наверное так и должно быть

fxposter (00:51:14 20/04/2008)
блин :)

fxposter (00:51:21 20/04/2008)
я этот разговор выложу на блог :)

fxposter (00:51:32 20/04/2008)
твоё имя упоминать? :)

mihailt (00:51:47 20/04/2008)
давай

mihailt (00:51:59 20/04/2008)
дашь травки немного

mihailt (00:52:00 20/04/2008)
)

fxposter (00:52:04 20/04/2008)
ага :)

mihailt (00:52:17 20/04/2008)
продолжая

mihailt (00:52:29 20/04/2008)
какая разница то, чего именно мы инкапсулируем?

fxposter (00:53:00 20/04/2008)
в смысле?

fxposter (00:53:10 20/04/2008)
я не совсем так выразился

mihailt (00:53:11 20/04/2008)
есть объект и мы с ним работаем

fxposter (00:53:17 20/04/2008)
не инкапсулируем

fxposter (00:53:24 20/04/2008)
хотя и инкапсулируем то же

fxposter (00:53:27 20/04/2008)
*тоже

mihailt (00:53:33 20/04/2008)
нее погоди

mihailt (00:53:38 20/04/2008)
я щас

fxposter (00:54:04 20/04/2008)
мы убираем дублирование пряча в один обьект функции/данные и т.д., которые отвечают за нечто общее

mihailt (00:54:13 20/04/2008)
во

mihailt (00:54:30 20/04/2008)
а что общее нам обсолютно пофиг

mihailt (00:54:38 20/04/2008)
абсолютно

fxposter (00:54:43 20/04/2008)
ну естественно :)

fxposter (00:55:03 20/04/2008)
опять же - два недостатка:

1. дублирование
2. решение одной задачи во многих местах - расплылось решение по разным классам/функциям/файлам

fxposter (00:55:09 20/04/2008)
вот они во всей красе

mihailt (00:55:36 20/04/2008)
так а чего дублируется то?

fxposter (00:55:46 20/04/2008)
возьмем select

mihailt (00:56:06 20/04/2008)
я кароче походу врубился что зенд_форм хорошая вещь

mihailt (00:56:11 20/04/2008)
:)

fxposter (00:56:25 20/04/2008)
возьмем селект

fxposter (00:56:56 20/04/2008)
function select(table, array columns, where)

fxposter (00:57:02 20/04/2008)
можно еще добавить всего

fxposter (00:57:09 20/04/2008)
order там и прочее

fxposter (00:57:32 20/04/2008)
если у нас на каждую таблицу 1 класс - то мы и table убираем

mihailt (00:57:58 20/04/2008)
ну и где дублирование?

fxposter (00:58:06 20/04/2008)
и получается, чтобы вместо “SELECT columns FROM TABLE WHERE” и т.д. мы вызываем одну функцию

mihailt (00:58:25 20/04/2008)
угу ты придумал хелпер

fxposter (00:58:32 20/04/2008)
:)

fxposter (00:58:42 20/04/2008)
я придумал active record еще скажи :)

fxposter (00:58:59 20/04/2008)
это обычный table gateway (есть такой паттерн)

mihailt (00:59:39 20/04/2008)
у банды в четырёх он есть?

fxposter (00:59:42 20/04/2008)
нет

fxposter (00:59:47 20/04/2008)
он у фаулера есть

mihailt (00:59:52 20/04/2008)
ок

fxposter (00:59:53 20/04/2008)
в Patterns of EEA

fxposter (00:59:55 20/04/2008)
или EAA

fxposter (00:59:58 20/04/2008)
:)

fxposter (01:00:12 20/04/2008)
или AAE

fxposter (01:00:15 20/04/2008)
блие

fxposter (01:00:17 20/04/2008)
блин

mihailt (01:00:18 20/04/2008)
типа ентерпрайз чего-то там?

fxposter (01:00:23 20/04/2008)
ага

mihailt (01:00:29 20/04/2008)
понял

fxposter (01:00:31 20/04/2008)
EAA

fxposter (01:00:35 20/04/2008)
всё-таки

mihailt (01:00:51 20/04/2008)
не суть давай дальше

fxposter (01:00:55 20/04/2008)
далее - насчет дублирования

fxposter (01:01:06 20/04/2008)
тебе нужно выбрать N статей

fxposter (01:01:10 20/04/2008)
в нескольких местах

fxposter (01:01:20 20/04/2008)
пишешь sql - вот тебе дублирование

fxposter (01:01:30 20/04/2008)
делаешь функцию с параметром N - вот его и нет

fxposter (01:01:46 20/04/2008)
+ код, который работает с бд обьединен в одном месте

mihailt (01:01:54 20/04/2008)
extends млин

fxposter (01:02:01 20/04/2008)
;)

mihailt (01:02:56 20/04/2008)
а ZF начинает такое делать для ХНТМL

fxposter (01:03:05 20/04/2008)
в смысле?

mihailt (01:03:23 20/04/2008)
в смысле зенд_форм

fxposter (01:03:50 20/04/2008)
там, кстати, насколько я помню еще и html поддерживается :)

fxposter (01:04:03 20/04/2008)
по крайней мере что-то с хелперами проскакивало

fxposter (01:04:13 20/04/2008)
типа - есть поле isXhtml

fxposter (01:04:34 20/04/2008)
и в зависимости от него оно input-хелперы раньше генерировало

mihailt (01:04:38 20/04/2008)
в итоге получаем что пхп деву с хтмл вобще работать не нужно будет

fxposter (01:04:51 20/04/2008)
не совсем

fxposter (01:05:00 20/04/2008)
вот форму нужно выводить

mihailt (01:05:16 20/04/2008)
не смотри

fxposter (01:05:16 20/04/2008)
ты можешь описать в самой форме -как ты её будешь выводить

fxposter (01:05:25 20/04/2008)
таблицами

fxposter (01:05:29 20/04/2008)
списками и т.д.

mihailt (01:05:36 20/04/2008)
погоди

fxposter (01:05:40 20/04/2008)
в каком-нибудь From_View

fxposter (01:05:44 20/04/2008)

mihailt (01:05:50 20/04/2008)
смотри

fxposter (01:05:57 20/04/2008)
экземпляр которого будет храниться в Zend_From

fxposter (01:05:58 20/04/2008)
lf

fxposter (01:05:59 20/04/2008)
да

mihailt (01:06:35 20/04/2008)
у нас есть код который берет чего нить из бд и создаёт структуру докумунта

mihailt (01:06:47 20/04/2008)
семантически правилный

fxposter (01:07:00 20/04/2008)
это ты к Zend_Form

fxposter (01:07:06 20/04/2008)
или вообще

fxposter (01:07:07 20/04/2008)
?

mihailt (01:07:23 20/04/2008)
вобще более глобально

fxposter (01:07:26 20/04/2008)
ага

fxposter (01:07:27 20/04/2008)
ну

mihailt (01:07:38 20/04/2008)
делаем это так

mihailt (01:07:51 20/04/2008)
после того как получили пишем

mihailt (01:08:14 20/04/2008)
$output = new $html;

mihailt (01:08:40 20/04/2008)
а дальше appendChild

fxposter (01:08:49 20/04/2008)
гм

fxposter (01:09:00 20/04/2008)
тебя куда-то не туда понесло

fxposter (01:09:03 20/04/2008)
ты о чем?)

mihailt (01:09:21 20/04/2008)
ну смотри что делает зенд_форм?

mihailt (01:09:27 20/04/2008)
генерит форму

fxposter (01:09:41 20/04/2008)
смотри

fxposter (01:09:46 20/04/2008)
в общем случае

fxposter (01:09:57 20/04/2008)
ты, например, наследуешь от зенд-форм

mihailt (01:10:00 20/04/2008)
а в чем проблема сделать класс который будет весь документ генерит?

fxposter (01:10:13 20/04/2008)
и указываешь ему, какие поля и что должно там быть

fxposter (01:10:29 20/04/2008)
проблемы нет

fxposter (01:10:38 20/04/2008)
тебе View’ха его и генерит по сути

fxposter (01:10:39 20/04/2008)

fxposter (01:11:23 20/04/2008)
а вообще - да, можно на всё делать обьекты

fxposter (01:11:30 20/04/2008)
собственно, DOM - это оно и есть

mihailt (01:11:32 20/04/2008)
мне это почему то XSLT очень силно напоминает

mihailt (01:11:54 20/04/2008)
правда я с ним не работал

fxposter (01:11:55 20/04/2008)
только не очень удобно работать на этом уровне с тегами

fxposter (01:11:58 20/04/2008)
я тоже

fxposter (01:12:07 20/04/2008)
вот что-то типа такого

mihailt (01:13:06 20/04/2008)
но в принципе получается правилно, программист занят своим делом а именно составлением программы и обработкой данных а остальное его не касается

fxposter (01:13:28 20/04/2008)
$doc = new Document($content); // content - то, что получили из базы
$doc->setSidebar($sidebar); // если нам нужно использовать не default’ный sidebar, например

fxposter (01:13:54 20/04/2008)
давай опустимся несколько ниже

fxposter (01:13:58 20/04/2008)
на уровень MVC

mihailt (01:14:05 20/04/2008)
давай

fxposter (01:14:17 20/04/2008)
есть модель, есть её вьюха, есть контроллер

mihailt (01:14:28 20/04/2008)
кастати мне его в последнее время не хватает

mihailt (01:14:40 20/04/2008)
ок

fxposter (01:14:52 20/04/2008)
пойми, что то, что реализовано в фреймворках - это не единое применение

fxposter (01:15:00 20/04/2008)
берем Zend_Form

fxposter (01:15:13 20/04/2008)
модель - это поля, валидаторы и прочее

fxposter (01:15:21 20/04/2008)
именно логически

mihailt (01:15:40 20/04/2008)
ну

fxposter (01:15:44 20/04/2008)
контроллер - какие-нибудь внутренние события, обработчики и т.д.

fxposter (01:15:56 20/04/2008)
в данном случае мне придмать что-то сложно

fxposter (01:16:12 20/04/2008)
а view’ха - это то, что из себя эта форма представляет в html

mihailt (01:16:32 20/04/2008)
погоди ты к чему? типа куда зенд_форм?

fxposter (01:16:36 20/04/2008)
т.е. мы разделили сам Zend_Form на MVC-составляющие

mihailt (01:16:42 20/04/2008)
аа ну

fxposter (01:17:00 20/04/2008)
> но в принципе получается правилно, программист занят своим делом а именно составлением программы и обработкой данных а остальное его не касается

fxposter (01:17:24 20/04/2008)
программист даже в Zend_Form может заняться моделью и контроллером

fxposter (01:17:35 20/04/2008)
оставив вьюху верстальщику

mihailt (01:17:47 20/04/2008)
именно

fxposter (01:17:50 20/04/2008)
т.е. всё так же, как и с обычными страницами

fxposter (01:18:02 20/04/2008)
только на следующем уровне

fxposter (01:18:07 20/04/2008)
внутри самой страницы

fxposter (01:18:18 20/04/2008)
и так можно описывать любые элементы страницы

fxposter (01:18:26 20/04/2008)
хедер, футер, меню, логотип

fxposter (01:18:31 20/04/2008)
как тебе удобно

fxposter (01:18:37 20/04/2008)
но это в теории

mihailt (01:18:37 20/04/2008)
ну это уже NMVC получается, нет?

fxposter (01:18:46 20/04/2008)
что такое N?

mihailt (01:18:56 20/04/2008)
типа nested

fxposter (01:18:57 20/04/2008)
на практике такое вряд ли будет

fxposter (01:19:01 20/04/2008)

fxposter (01:19:13 20/04/2008)
я такой терминологии не слышал, но так сказать можно

mihailt (01:19:46 20/04/2008)
ну компонетный подход где каздй компонет проектируется по MVC

fxposter (01:20:01 20/04/2008)
честно?

mihailt (01:20:08 20/04/2008)
?

fxposter (01:20:08 20/04/2008)
я с таким подходом не знаком

mihailt (01:20:19 20/04/2008)
гм

fxposter (01:20:25 20/04/2008)
т.е. я представляю, что оно такое

fxposter (01:20:34 20/04/2008)
но никогда в лоб не сталкивался

fxposter (01:20:41 20/04/2008)
почему формы сюда попали (в категорию выделяемых в отдельный обьект), а остальные компоненты - нет

fxposter (01:21:24 20/04/2008)
ну во первых, формы - это более общее понятие, типа Page, Document и т.д., ккоторые уже на MVC как раз разделены. А еще потому, что формы нужно обрабатывать

fxposter (01:21:30 20/04/2008)
на сервере

mihailt (01:22:11 20/04/2008)
кстати про валидацию

mihailt (01:22:37 20/04/2008)
в последнее время не вижу смысла в ней на стороне клиента

fxposter (01:22:42 20/04/2008)

fxposter (01:23:01 20/04/2008)
ну у меня к валидации смешанные чувства

mihailt (01:23:08 20/04/2008)
осjбенно при работе с ajax

fxposter (01:23:09 20/04/2008)
стараюсь делать код валидным

fxposter (01:23:19 20/04/2008)
но в принципе - не гонюсь за этим

mihailt (01:23:29 20/04/2008)
нее

mihailt (01:23:37 20/04/2008)
я про валидацию данных

mihailt (01:23:43 20/04/2008)
из формы

fxposter (01:23:56 20/04/2008)
а

fxposter (01:24:06 20/04/2008)
я её никогда не делал

fxposter (01:24:14 20/04/2008)
смысл вижу явно

fxposter (01:24:20 20/04/2008)
но не делал

mihailt (01:24:34 20/04/2008)
стандартная хрен форма-валидация(клиент)-валидация(сервер)

fxposter (01:24:39 20/04/2008)
смысл - БЫСТРО, реально БЫСТРО сказать пользователю, что он ввел фигню

mihailt (01:25:30 20/04/2008)
при использовани ajax все равно не вижу

fxposter (01:25:50 20/04/2008)
пройдет пол секунды, пока ты получишь ответ с сервера

fxposter (01:25:56 20/04/2008)
в лучшем случае - меньше

fxposter (01:26:06 20/04/2008)
но не абсолютно быстро

mihailt (01:26:34 20/04/2008)
зато не будет безумных алёртов

fxposter (01:26:42 20/04/2008)
+ нет дополнительных запросов к серваку, но для меня это на данный момент пока что не главный фактоп

fxposter (01:26:45 20/04/2008)
фактор

fxposter (01:27:05 20/04/2008)
> зато не будет безумных алёртов
не обязательно делать алерты

mihailt (01:27:16 20/04/2008)
а если так же апдейтит див то вобще пофиг запрос всё равно есть

fxposter (01:27:27 20/04/2008)
можно сделать сообщения об ошибках неотличимыми при серверной проверке и клиентской

fxposter (01:28:02 20/04/2008)
я тебе могу сказать одно

mihailt (01:28:11 20/04/2008)
типа генерить хтмл во внутрь елемента по ид?

fxposter (01:28:13 20/04/2008)
валидация на клиенте не необходима

fxposter (01:28:15 20/04/2008)
но удобна

fxposter (01:28:21 20/04/2008)
да

fxposter (01:28:25 20/04/2008)
или просто по селектору

fxposter (01:28:29 20/04/2008)
непринципиально

mihailt (01:28:46 20/04/2008)
ну допустим

mihailt (01:28:47 20/04/2008)
но

mihailt (01:28:58 20/04/2008)
получается тоже саме дублирование

fxposter (01:29:05 20/04/2008)
ага

fxposter (01:29:11 20/04/2008)
но на разных уровнях

fxposter (01:29:18 20/04/2008)
это раз

fxposter (01:29:50 20/04/2008)
и два - в теории никто не запрещает делать так, чтобы тот же Zend_From генерировал код с проверками на клиенте

fxposter (01:30:04 20/04/2008)
т.е. описываем мы форму 1 раз

fxposter (01:30:13 20/04/2008)
а проверки оно всё само делает

mihailt (01:30:36 20/04/2008)
хрено получается на мой взгляд, код смешивается

fxposter (01:30:48 20/04/2008)
нет

mihailt (01:30:54 20/04/2008)
в смысле в самом зенд_форм

fxposter (01:30:57 20/04/2008)
нет

fxposter (01:31:04 20/04/2008)
Zend_Form_View

fxposter (01:31:11 20/04/2008)
такого класса, наверное, нет

fxposter (01:31:16 20/04/2008)
но суть понятна

mihailt (01:31:21 20/04/2008)
:D

fxposter (01:31:23 20/04/2008)
ты наследуешься от него

fxposter (01:31:45 20/04/2008)
и в зависимости от валидаторов серверных - делаешь js-проверки

mihailt (01:32:13 20/04/2008)
придумали новый класс в zf’е осталось только написать и заккомитить

mihailt (01:32:19 20/04/2008)
:D

fxposter (01:32:22 20/04/2008)
не думаю

fxposter (01:32:42 20/04/2008)
всё равно там zend-form разделено на модель и представление

fxposter (01:32:44 20/04/2008)
или нет?

fxposter (01:32:54 20/04/2008)
я не знаю, я zend-form не использовал

fxposter (01:33:05 20/04/2008)
я больше по symfony 1.1 forms сужу

fxposter (01:33:12 20/04/2008)
но суть работы та же

fxposter (01:33:55 20/04/2008)
т.е. можешь считать, что я тут говорил о неком Zend_Form, который в чем-то от настоящего Zend_Form отличается

fxposter (01:34:06 20/04/2008)
но суть не меняет

mihailt (01:34:39 20/04/2008)
setAction(’/usr/login’)
->setMethod(’post’);

// Create and configure username element:
$username = $form->createElement(’text’, ‘username’);
$username->addValidator(’alnum’)
->addValidator(’regex’, false, array(’/^[a-z]+/’))
->addValidator(’stringLength’, false, array(6, 20))
->setRequired(true)
->addFilter(’StringToLower’);

// Create and configure password element:
$password = $form->createElement(’password’, ‘password’);
$password->addValidator(’StringLength’, false, array(6))
->setRequired(true);

// Add elements to form:
$form->addElement($username)
->addElement($password)
// use addElement() as a factory to create ‘Login’ button:
->addElement(’submit’, ‘login’, array(’label’ => ‘Login’));
?>

fxposter (01:34:56 20/04/2008)
мм

fxposter (01:35:08 20/04/2008)
я бы всё это сделал в наследние Zend_Form’а

fxposter (01:35:30 20/04/2008)
и мог бы потом reuse’ить такую форму логина во многих местах

mihailt (01:35:58 20/04/2008)
ну это нормально

mihailt (01:36:26 20/04/2008)
я про клентскую часть

mihailt (01:36:40 20/04/2008)
$username->addValidator(’alnum’)

mihailt (01:37:00 20/04/2008)
$username->addValidator(’alnum’,'clientside’)

mihailt (01:37:11 20/04/2008)
ну или что то типо того

mihailt (01:37:30 20/04/2008)
по моему нормально

fxposter (01:38:22 20/04/2008)
да

fxposter (01:38:36 20/04/2008)
в зенде есть zend_from_decorator

fxposter (01:38:47 20/04/2008)
который отвечает за отрисовку этого всего в html

fxposter (01:38:55 20/04/2008)
судя по всему

mihailt (01:40:00 20/04/2008)
угу принимет 3 аргумента

mihailt (01:40:39 20/04/2008)
содержимое, элемент и параметры

mihailt (01:40:50 20/04/2008)
смотрю на ман

mihailt (01:41:35 20/04/2008)
в принципе его для такого дела тоже можно заюзать

fxposter (01:43:01 20/04/2008)
ну вот он и должен в зависимости от валидаторов серверных, добавленных к элементу писать дополнительный js-код

fxposter (01:44:41 20/04/2008)
отдельные валидаторы для клиента прописывать - имхо, не есть хорошо. хотя - всё может быть.

fxposter (01:44:44 20/04/2008)
ы

mihailt (01:44:51 20/04/2008)
хмм

mihailt (01:45:01 20/04/2008)
во

mihailt (01:45:03 20/04/2008)
Zend_Form_Decorator_Errors

fxposter (01:45:05 20/04/2008)
кстати, еще хорошо бы в валидаторы добавить
Zend_Validator_View

fxposter (01:45:07 20/04/2008)
)))))))))0

mihailt (01:45:12 20/04/2008)
вот он должен

fxposter (01:45:25 20/04/2008)
нет

fxposter (01:45:30 20/04/2008)
он выводит ошибки

fxposter (01:45:33 20/04/2008)
просто выводит

fxposter (01:45:38 20/04/2008)
если они уже найдены

mihailt (01:46:46 20/04/2008)
хмм

mihailt (01:46:49 20/04/2008)
тоже верно

fxposter (01:46:49 20/04/2008)
в общем, тут долго можно размышлять

fxposter (01:47:00 20/04/2008)
но вряд ли это будет сделано в таком виде

mihailt (01:47:13 20/04/2008)
даа ZF можно очень долго копать

fxposter (01:47:23 20/04/2008)

fxposter (01:47:25 20/04/2008)
угу

fxposter (01:47:42 20/04/2008)
ладно, пойду я спать

mihailt (01:47:57 20/04/2008)
даа, чего то я тоже засиделся

mihailt (01:48:03 20/04/2008)
но поговорили хорошо

fxposter (01:48:09 20/04/2008)
ага

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

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

Собственно, всё начинается с создания проекта (project) и приложений (applications) в нем. Как это делается — можно почитать в книжке (ссылка приведена выше), а мне бы хотелось остановиться на обьяснении того, что такое проект и принципах выбора приложений в нем — какие им дать имена, как их структурировать и т.д.

Проект

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

Приложения

В отличии от Django — здесь приложение не является атомарной единицей системы, которую можно использовать в других проектах… В Symfony они созданы лишь для того, чтобы логически (ну, и физически) разграничить функциональность вашего проекта. И самое главное — приложения имеют место быть только в рамках одного проекта. Т.е. если вы в рамках проекта удалите одно приложение — другие от этого не пострадают, но вот перенести из одного проекта в другой приложение будет очень проблематично, т. к. оно зависит от настроек проекта, от модели проекта и так далее.

Будет нелишним сказать, что официально рекомендовано (читать как «предлагается») в проекте создавать два приложения: frontend и backend (для русскоязычной аудитории термин «админка» в данном случае будет более уместен). Сам могу порекомендовать создавать приложения только для объединения модулей, которые ставят перед собой одну цель. Например, та же админка, пользовательский интерфейс (то есть, например, профиль пользователя, всё, что пользователь может изменять на сайте) и frontend (всё, что доступно всем).

Сам я пользуюсь рекомендацией книги и имею два приложения в своем проекте.

Плюсы и минусы такого подхода мне рассматривать не хочется. Скажу лишь, что для меня Django’вский подход гораздо более удобен и логичен, и вот эти проекты/приложения для новичка выглядят достаточно сложно и непонятно, в большинстве случаев новички просто слушаются рекомендаций книги, не совсем понимая, что это и зачем это нужно. Я бы на месте разработчиков Symfony подумал бы о пересмотре этого подхода, особенно, если учитывать, что плагины в Symfony — это по сути те же Django apps, но об этом несколько позже.

Окружения (environments)

Останавливаться на окружениях особенно не хочется. Это очень удобный, но в то же время очень простой механизм, обеспечивающий возможность заходить в одно и то же приложение с различными серверными настройками. Если сказать проще — представьте себе, что у вас есть приложения и галочка, которая переключает режим его работы в debug-mode и обратно. В debug-mode, например, все события логгируются, все ошибки выводятся на экран и т.д. Если же debug-mode выключен — все логи выключены, и на экране никогда никаких ошибок появляться не будет. Так вот — в Symfony вместо флага debug/не-debug имеется просто несколько различных окружений, каждое из которых можно настроить ПОЛНОСТЬЮ, т. е. не система решает — что включить, а что выключить, а вы сами. Хочется также отметить, что особо копаться в настройках вам не прийдется — по умолчанию для каждого приложения создается 3 environment’а: production, development, testing (используется исключительно при тестировании).

В общем, тут придраться не к чему — всё, на мой взгляд, просто идеально.

Модули (modules)

… содержат в себе контроллер с действиями и представления (т.е. MV из MVC), а также конфигурационные файлы и, возможно, библиотеки, нужные только в этом конкретном модуле. Тут всё достаточно просто и понятно.

Модули (как и приложения с проектом) можно создавать автоматически (и помощью командной строки). Кроме создания простого модуля можно создать (опять же — автоматически) CRUD (Scaffolding) для одной из таблиц, либо админку (опять же, для одной из таблиц). Админка отличается тем, что никакого кода писать практически не нужно — почти всё в ней (фильтрация, сортировка и т.д.) настраивается с помощью конфигурационного файла, что ОЧЕНЬ удобно (привет джангистам, они поймут). CRUD же очень полезен при начальных стадиях разработки. Пример — добавили вы таблицу пользователей, теперь вам нужно: выводить список пользователей, позволять им редактировать свой профиль и регистрироваться. Вместо того, чтобы всё писать с самого начала — создаем CRUD-модуль для таблицы пользователей, а потом уже можно начинать писать свой код, основываясь на уже сгенерированном. В неявный плюс такого решения можно отнести то, что коды модулей получаются похожими друг на друга и путаницы возникает меньше.

Последнее, на чем хотелось бы остановиться — это…

Модели (models)

Все модели хранятся в одном (или нескольких) YAML-файлах. К написанию моделей привыкаешь за 3—4 дня. Из YAML модель с помощью одной комманды преобразуется в автоматически сгенерированные базовые классы ORM (Propel или Doctrine). Всё быстро, просто и аккуратно.

Пожалуй, это всё, что может понадобиться новичку при изучении Symfony (чтобы она не казалась ему какой-то сложной и непонятной системой, какой она мне показалась год назад).

А вот теперь перейдем непосредственно к моим рекомендациям. Но перед этим я расскажу вам про…

Плагины (plugins)

Плагины — это, по сути, тот код, который может быть использован несколько раз в разных проектах и приложениях. Плагины могут содержать:

• конфигурационные файлы, в том числе свои модели (!!!)
• модули
• библиотеки

Я могу оказаться не прав, но как мне кажется, плагины — это такие себе мини-проекты, «всё в себе», чем выгодно отличаются от Symfony applications. На мой взгляд, ставку стоило делать в первую очередь на них — убрать приложения, а вместо них поставить плагины и создать некий инструмент, который бы позволил эти плагины связывать между собой.

Мои рекоммендации

• В первую очередь — проектирование. Не скупитесь на этом шаге, анализируйте и уточняйте у заказчика непонятные пункты.
• Видя перед собой (да хоть в уме) макет системы — продумайте, на какие части систему можно разбить.
• Поищите среди существующих плагинов такие части (обязательно). Я в своем проекте использовал следующие плагины:
  • sfGuardPlugin — user management, security и т.д. Плагин - must have.
  • sfDateTimePlugin — очень удобная работа с датами и временем
  • sfPropelAlternativeSchemaPlugin — полезен при работе с плагинами, позволяет менять модели, прописанные в плагинах, не изменяя коды самих плагинов
  • sfPropelApprovableBehaviorPlugin — мне очень пригодился при «активации пользователей»
  • sfThumbnailPlugin — уменьшение картинок (не смотрите на название — с ресайзом 3MP-фотографий к 800×600 плагин справляется на отлично)
  • sfPropelActAsTaggableBehaviorPlugin — если вам нужны тэги
  • sfPropelActAsSluggableBehaviorPlugin — если вам нужны slug’и (а я советую их использовать — очень хорошо сказывается на читаемости url’ов, когда вместо id туда засовывать slug’и)
  • sfPropelActAsRatableBehaviorPlugin — рейтинги, довольно крутые, мне, к сожалению, не подошли…
  • sfPropelActAsCommentableBehaviorPlugin — всё, что нужно для комментариев
• Используйте в работе автоматически генерируемые CRUD-модули и модули для админки

Вот, пожалуй, и всё на сегодня. Жду ваших комментариев.

Давно у меня таких больших статей не было…

Запостил на Хабрахабр.

Zend Framework в MVC

Для начала - моя цитата:

А я все больше склоняюсь к Django. :)
А по поводу ZF меня все больше посещают такие мысли: стройным и красивым он кажется только на первый взгляд и именно из-за того, что у нас по сути получается набор классов, которые нам самим предложено связывать. Другие фреймворки нам предоставляют уже готовую структуру каталогов и некоторые “настройки по умолчанию”, а в Zend’е это все нужно делать самому. И в итоге после настройки фреймворка под себя он все больше становится “некрасивым” и похожим на другие фреймворки. :)

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

Zend Framework как библиотека классов

А вот как библиотеку классов ZF использовать не только можно, но и нужно. Я вот на себе прочувствовал, насколько удобно работать с почтой через Zend_Mail по сравнению со стандартными функциями imap_*. Да и Zend_Db и Zend_Log юзать достаточно удобно.

Писал недавно скрипт, который загружает файлы с POP3-сервера, парсит их и загружает в бд. Сначала написал просто функциями стандартными, а потом переписал с использованием ZF - код стал намного боле красивым, более легким в понимании и сократился в 2 раза. Так что в этой ипостаси ZF, на мой взгляд, идеальное замена многих модулей стандартной библиотеки PHP. Также радует наличие во фреймворке работы со всякими Web-сервисами - Amazon, del.icio.us, Flickr, и это еще не полный список, к тому же разработчики ZF планируют развивать фреймворк именно в этом направлении.

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

Теперь о Zend’е - 6-го числа вышла новая версия (а на офсайте нагло врут, что 4-го!). Опять дофига изменений по сравнению с предыдущей версией: планомерно дорабатывают Model, представленную здесь Zend_Db_Table, добавили, пока еще не вьехал зачем, helper’ы к Controller’у, и целая куча других изменений.

PS. До утра попробую накатать небольшой расказ про Zend_Db_Table и возможные способы его улучшения.