вы меня не поняли, сори. Я говорю о крупных проектах, которые занимают 1Мегабайт целиком, а вы мне про 15 мегабайтный фреймворк, на котором еще библиотеки, да еще надо писать логику программы сверху на этом всем. Вы разницу себе представляете?
да, стоит. Хотя бы потому что шаблонизаторы могут СОХРАНЯТЬ чистый отрендеренный HTML и повторно его не будут рендерить и дергать php (типа кеша такого).
Это написано весьма недурными спецами, они поняли что лучше сделать бордюрчик в виде echo ' чем потом разбираться в "<?php. Это вообще-то SquirrelMail
простите, он же весит под 15МБ, да еще библиотеки эти… Можете на глаз сказать сколько метров кода реально проходит через парсер php при одном вызове среднестатистической странички?
в мусоре в виде "<?php".
и чем больше вставок, тем больше мусора. Проще уже тогда как в посте картинка номер 2. там хотя-бы пробелами код HTML от echo отделили :)
понятие модульности достаточно абстрактно, я понимаю под модулем логическую атомарную единицу (сущность) с которой можно произвести полный спектр действий insert/update/delete… соотв. за это отвечает индивидуальные плагины, каждый из которых занимается сугубоб своим делом, лишний код не подключается и время на его парсинг не затрачивается. Например, модуль customer — понятно что в нем обрабатывается абонент, а не тарифные планы. Общие валидаторы, типа is_digital, is_email, is_??? у всех одинаковые они везде есть, даже в самом PHP встроено. Некоторые, типа is_ip, is_mac, is_date надо доделать самому (интересно есть подобное в толстых фреймворках?).
Абсолютно точно ОДНА! и даже не библиотека, а тупой свитчер. Я согласен, сейчас многие не могут представить себе жизни без класса метра на 3 весом.
Как я объясню что у меня функционал почти весь внутри SQL (в pl/sql), а php используется только для дерганья $db->query(«select
чтобы не получался код HTML вперемешку с echo и print, которые тупо замусоривают код HTML своими <?php echo или <?= $var. Гораздо проще редактировать чистый HTML без вкраплений логического мусора php.
В том и дело что я видел что там внутри. Например это:
— <td class="<?php echo implode(' ', $classes) ?>"><span class=«day»><?php echo $day[0] ?></span><?php echo $output ?></td>
— и это
— // Load the session
$query = $this->db->from($this->table)->where('session_id',$id)->limit(1)->get()->result(TRUE);
— и это
— $stmt = $this->db->prepare(«SELECT `t`.`title`, `v`.`name`, `ts`.`id` AS `type_id`, `ts`.`name` AS `type`, `ts`.`title` AS `typetitle`,
IFNULL(`val`.`value`, `val_def`.`value`) as `value` FROM `sys_cfg` `cfg_def`
INNER JOIN `sys_cfg_values` `val_def` ON `val_def`.`cfg_id` = `cfg_def`.`id` AND `cfg_def`.`section` = 0
LEFT JOIN `sys_sections` `s` ON `s`.`name` = :section
LEFT JOIN `sys_modules` `m` ON `m`.`name` = :module
LEFT JOIN `sys_cfg` `cfg` ON `cfg`.`section` = `s`.`id` AND `cfg`.`module` = `m`.`id`
LEFT JOIN `sys_cfg_values` `val` ON `val`.`cfg_id` = `cfg`.`id` AND `val`.`name` = `val_def`.`name`
INNER JOIN `sys_cfg_vars` `v` ON `v`.`id` = `val_def`.`name`
LEFT JOIN `sys_cfg_titles` `t` ON `t`.`id` = `val_def`.`title`
LEFT JOIN `sys_cfg_types` `ts` ON `ts`.`id` = `val_def`.`type_id`
WHERE `cfg_def`.`module` = `m`.`id`»);
не, пока что на серваке Debian Lenny. А надо перенести на D:? там у меня фильмы всякие, музычка. Хотя да, надо сделать бекап с unix'a на D:, а то еще винт посыпется…
1. Про дефолтовые действия согласен. Можно $object и $task не обнулять, а присваивать им дефолты.
Также маршрутизатор разделен на две части. Это означает что может сработать ПРЕпроцессор одного плагина, а отрисовка будет от другого плагина. Это ключевой момент!
2. Рассматриваю этот фреймворк как фундамент, а будет ли на нем стоянка для автомобилей или небоскреб — это дело кодера. Кирпич ему в руки (одному PDO, Dwoo, JQuery, другому AdoDB, Smarty, Prototype).
3. Это все входит в понятие валидации.
PS Я тут упустил кое-что. Дело в том, что я ~30-50% логики из php вынес в PosgreSQL (plpgsql), фактически, php нужен лишь для того чтобы подготовить данные и сделать $db->query(). Может поэтому мне хватает такого «прозрачного дергателя плагинов» ;-)
1. $action изготовляется методом апачевского rewrite. Не вижу смысла менять URI на другой. Если же надо, то правим не фреймворк, а rewruterule в .htaccess. (как-то так ^/(.+?)/(.+)$ /?action=$1_$2)
При отсутствии параметров отправит в «Incorrect action», поскольку $object и $task не определены.
2. Да, функциональные блоки будут расширяться, при этом не затрагивая сам фреймворк.
3. Проследим путь аплоада аватарки.
* $action=«user_update»
* в user.pre.php валидация полей, включая парсинг аватарки (по успеху UPDATE данных в SQL), user.pre.php выходит по exit!
* если все ок, то возвращаем через json result=>success (либо result=>error,avatar=>«ошибка формата»)
* на клиенте подсвечиваем «данные изменены», либо подсвечиваем поле с id=avatar и выводим на нем попап «ошибка формата»
* страница на клиенте не меняется, поскольку через AJAX модуль PRE передал лишь нужный ответ.
** если надо редиректить юзера после аплоада аватарки, то передаем через тот же json redirect=>"/user_show" (ID юзера берем в $_SESSION)
4. Вырос не сам фреймворк, а мясо на его скелете.
механизм валидации есть. Используется в PRE модулях, и да, это 1 класс. Но он пока не стал частью фреймворка. Спасибо за советы, господа, я использую их в развитии фреймворка добавив в него необходимый минимум.
1. Вот так: /объект_действие/<ID> (в случае когда этого мало, можно структурировать его иначе — это зависит от конкретной задачи)
2. С БД работаем через класс DB (который наследован от любого ивестного вам API). В классе DB тоже присутствует диспетчер и мягкие
корректоры данных под конкретную задачу. Понятие «Каждый контроллер» не использую, их один.
3. Надобности кешировать данные пока не возникало. Может это мое упущение… надо будет озаботиться где бы мне это понадобилось.
4. По правде сказать не работал с изображениями… Вероятно в этом плане есть сложности, которые мне пока неизвестны. В качестве капча
берется опять же любой свежий класс, который прошел очередное тестирование на ботов :)
5. Авторизация и ACL — да, это надо будет описать подробнее… хотя, судя по коментам, это мало кому интересно :)
Сорри, не писал систему планетарной обработки данных, поэтому фреймворк можно рассматривать как узкоспециализированный :) С БД можно работать через PDO или тот API, который вам известен. Кеш берет на себя шаблонизатор, может сохранять чистые HTML и вообще не использовать php для рендеринга. Плиз, дайте ссылку на посмотреть где реализация подобного фреймворка красива на ваш взгляд.
а что можно ставить в пример? Есть какие-то ограничения?
Это написано весьма недурными спецами, они поняли что лучше сделать бордюрчик в виде echo ' чем потом разбираться в "<?php. Это вообще-то SquirrelMail
и чем больше вставок, тем больше мусора. Проще уже тогда как в посте картинка номер 2. там хотя-бы пробелами код HTML от echo отделили :)
2. см. п.1
PS Смарти не надо, лучше учить Dwoo. Да, минут 15 надо потратить на это «изучение» :)
Как я объясню что у меня функционал почти весь внутри SQL (в pl/sql), а php используется только для дерганья $db->query(«select
Какой вы посоветуете фреймворк?
— <td class="<?php echo implode(' ', $classes) ?>"><span class=«day»><?php echo $day[0] ?></span><?php echo $output ?></td>
— и это
— // Load the session
$query = $this->db->from($this->table)->where('session_id',$id)->limit(1)->get()->result(TRUE);
— и это
— $stmt = $this->db->prepare(«SELECT `t`.`title`, `v`.`name`, `ts`.`id` AS `type_id`, `ts`.`name` AS `type`, `ts`.`title` AS `typetitle`,
IFNULL(`val`.`value`, `val_def`.`value`) as `value` FROM `sys_cfg` `cfg_def`
INNER JOIN `sys_cfg_values` `val_def` ON `val_def`.`cfg_id` = `cfg_def`.`id` AND `cfg_def`.`section` = 0
LEFT JOIN `sys_sections` `s` ON `s`.`name` = :section
LEFT JOIN `sys_modules` `m` ON `m`.`name` = :module
LEFT JOIN `sys_cfg` `cfg` ON `cfg`.`section` = `s`.`id` AND `cfg`.`module` = `m`.`id`
LEFT JOIN `sys_cfg_values` `val` ON `val`.`cfg_id` = `cfg`.`id` AND `val`.`name` = `val_def`.`name`
INNER JOIN `sys_cfg_vars` `v` ON `v`.`id` = `val_def`.`name`
LEFT JOIN `sys_cfg_titles` `t` ON `t`.`id` = `val_def`.`title`
LEFT JOIN `sys_cfg_types` `ts` ON `ts`.`id` = `val_def`.`type_id`
WHERE `cfg_def`.`module` = `m`.`id`»);
Также маршрутизатор разделен на две части. Это означает что может сработать ПРЕпроцессор одного плагина, а отрисовка будет от другого плагина. Это ключевой момент!
2. Рассматриваю этот фреймворк как фундамент, а будет ли на нем стоянка для автомобилей или небоскреб — это дело кодера. Кирпич ему в руки (одному PDO, Dwoo, JQuery, другому AdoDB, Smarty, Prototype).
3. Это все входит в понятие валидации.
PS Я тут упустил кое-что. Дело в том, что я ~30-50% логики из php вынес в PosgreSQL (plpgsql), фактически, php нужен лишь для того чтобы подготовить данные и сделать $db->query(). Может поэтому мне хватает такого «прозрачного дергателя плагинов» ;-)
При отсутствии параметров отправит в «Incorrect action», поскольку $object и $task не определены.
2. Да, функциональные блоки будут расширяться, при этом не затрагивая сам фреймворк.
3. Проследим путь аплоада аватарки.
* $action=«user_update»
* в user.pre.php валидация полей, включая парсинг аватарки (по успеху UPDATE данных в SQL), user.pre.php выходит по exit!
* если все ок, то возвращаем через json result=>success (либо result=>error,avatar=>«ошибка формата»)
* на клиенте подсвечиваем «данные изменены», либо подсвечиваем поле с id=avatar и выводим на нем попап «ошибка формата»
* страница на клиенте не меняется, поскольку через AJAX модуль PRE передал лишь нужный ответ.
** если надо редиректить юзера после аплоада аватарки, то передаем через тот же json redirect=>"/user_show" (ID юзера берем в $_SESSION)
4. Вырос не сам фреймворк, а мясо на его скелете.
2. С БД работаем через класс DB (который наследован от любого ивестного вам API). В классе DB тоже присутствует диспетчер и мягкие
корректоры данных под конкретную задачу. Понятие «Каждый контроллер» не использую, их один.
3. Надобности кешировать данные пока не возникало. Может это мое упущение… надо будет озаботиться где бы мне это понадобилось.
4. По правде сказать не работал с изображениями… Вероятно в этом плане есть сложности, которые мне пока неизвестны. В качестве капча
берется опять же любой свежий класс, который прошел очередное тестирование на ботов :)
5. Авторизация и ACL — да, это надо будет описать подробнее… хотя, судя по коментам, это мало кому интересно :)
PS Спасибки, изучу на досуге Kohana.