- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
- 54
- 55
- 56
- 57
- 58
- 59
- 60
- 61
- 62
- 63
- 64
- 65
- 66
- 67
- 68
- 69
- 70
- 71
- 72
- 73
- 74
- 75
- 76
- 77
- 78
<?php
class view {
protected $dir; //templates directory
protected $lang; //language
protected $authorized;
protected $user;
protected function getCache($template) {
//return false; //uncomment for developing
if (!isset($_SESSION['cache_' . $template])) return false;
return $_SESSION['cache_' . $template];
}
protected function addCache($template, $content) {
$_SESSION['cache_' . $template] = $content;
}
public function __construct($dir, localization $lang, user $user) {
$this->dir = $dir;
$this->authorized = (bool) $user->authorized;
$this->user = $user;
$this->lang = $lang;
}
public function invoke($template, $params = [], $return = false, $quests = []) { //can be called w/o params
$filename = ROOT . '/' . $this->dir . '/tpl/' . $template . '.tpl';
$lang = $this->lang->getData();
$content = $this->getCache($template);
if (!$content) {
$f = fopen($filename, 'a+');
$content = fread($f, (filesize($filename) > 0 ? filesize($filename) : 1));
$this->addCache($template, $content);
}
foreach ($params as $key => $value) {
$content = str_ireplace('{{' . $key . '}}', $value, $content);
}
preg_match_all("@{{:([a-z0-9_]+?)}}@sui", $content, $localization);
$localization = $localization[1];
foreach ($localization as $value) {
$content = str_ireplace('{{:' . $value . '}}', $lang[$value], $content);
} //applying lang
foreach ($quests as $key => $value) {
preg_match_all("@{\?$key=$value\?}(((?!{\?.+\?}).)*?){\?\?}@sui", $content, $matches);
while (!empty($matches[0])) {
$content = str_replace($matches[0][0], $matches[1][0], $content);
preg_match_all("@{\?$key=$value\?}(((?!{\?.+\?}).)*?){\?\?}@sui", $content, $matches);
}
preg_match_all("@{\?$key=((?!$value).+?)\?}(((?!{\?.+\?}).)*?){\?\?}@sui", $content, $matches);
while (!empty($matches[0])) {
$content = str_replace($matches[0][0], "", $content);
preg_match_all("@{\?$key=((?!$value).+?)\?}(((?!{\?.+\?}).)*?){\?\?}@sui", $content, $matches);
}
}
preg_match_all("@{\?access=([a-z0-9]+?)\?}(((?!{\?.+\?}).)*?){\?\?}@sui", $content, $perms);
while (!empty($perms[0])) {
foreach ($perms[1] as $value) {
if ($this->user->canAccess($value))
$content = preg_replace("@{\?access=$value\?}(((?!{\?.+\?}).)*?){\?\?}@sui", "$1", $content);
else $content = preg_replace("@{\?access=$value\?}(((?!{\?.+\?}).)*?){\?\?}@sui", "", $content);
}
preg_match_all("@{\?access=([a-z0-9]+?)\?}(((?!{\?.+\?}).)*?){\?\?}@sui", $content, $perms);
}
$content = preg_replace("@{\?authorized=((?!" . (int) $this->authorized . ").+?)\?}(.+?){\?\?}@sui", "", $content);
$content = preg_replace("@{\?authorized=" . (int) $this->authorized . "\?}(.+?){\?\?}@sui", "$1", $content);
$content = preg_replace("@{\?(.+?)\?}(.+?){\?\?}@sui", "", $content);
$content = str_ireplace('{{DIR}}', '/' . $this->dir, $content); //replacing DIR param
$content = str_ireplace('{{URI}}', urlencode(other::filter($_SERVER['REQUEST_URI'])), $content); //replacing URI param
$content = str_ireplace('{{HTTP_HOST}}', $_SERVER['HTTP_HOST'], $content); //replacing HTTP_HOST param
$content = preg_replace("@{\?((.+?)|(.+?){0})\?}@sui", "", $content);
if (!$return) echo $content;
return $content;
}
}
?>
Мой шаблонизатор. Детям и беременным женщинам не смотреть.
Follow us!
Их мало?
Нужно всегда написать свои ООП обертки для коллекций, свой шаблонизатор, свой CMS , свой форум и свою социальную сеть.
удачи!
на деле же даже jpa и прочий хайбернейт посасывают в заметной части случаев у обычных нативных запросов
Вот, в моих ГК есть запрос с группировкой, пол часа с ним еб*лся, хотя вроде и можно как-то проще сделать.
даже для mysql есть несколько способов в рамках общих правил sql
и даже без единого group by
не только в мускуле собсно
http://sqlfiddle.com/#!4/769c4/1
это просто был пример решения без групп бабайки
орм нужен для инкапсуляции поведения. Из базы вычитываем параметры объекта и вызываем методы, которые у себя внутри используют эти параметры. Получается универсальность. Сохранение объектом самого себя (по айди например) - как одно из инкапсулированных действий.
Остальную часть не очень понял, но инкапсуляция это безусловно один из плюсов ОРМ.
Итого плюсы орм:
1) собственно OR/M: маппинг кучи полей объекта в поля таблицы (и наоборот)
2) динамическое построение запросов в терминах объекта а не базы
3) кеш
4) в легких случаях относительная бд независимость
5) ну всякие плюшки вроде физической невозможности SQL injection и прочей херни
6) легкий CRUD аут оф бокс
3 - кэш тоже не часть орм, и тоже проще даже делать его на уровне всей коллекции
2 - динамическое построение запросов... ну это если sql, но орм имеет смысл и для nosql.
только 1 и есть - орм.
но тут не перечислено еще то, что какие-нибудь свойства объекта можно посчитать/преобразовать налету.
Насчет как сделать круд без преобразования в объект: ну пишем класс для всей коллекции в котором будут методы create, read, update, delete - не вижу проблем. Минус только в том что при сохранении нужно будет всегда таскать айдишник, но тут зависит от задачи. Если вы этот айдишник и так получили от юзера - че бы его и не пихнуть.
Большинство ОРМ умеют 1 и 2 (ну кроме майбатиса). Верно?
Тоесть человек или берет фреймворк с 1 и 2, или пишет SQL запросы руками и руками-же мапит результаты в объекты (ну мы же говорим об ООП).
И вот у человека есть шесть таблиц, в каждой по 15 полей. Без 1 и 2 ему нужно будет написать 4 * 6 тупых SQL запросов и 15 * 6 вызовов мутатора или установки значения в поле объекта.
Вот собссно про это я и говорил.
Я не против ОРМ, а за, но оно не 100% панацея ото всего. Иногда оно может и мешать. Я считаю ОРМ должно быть включаемым/выключаемым от задачи, от уровня необходимой инкапсуляции.
Круд как таковой не требует преобразования в объект (при равном количестве кода).
Вы же данные все равно в шаблонизатор пихнете - какая разница объекты там или ассоциативные массивы. Зачем накладные расходы?
Тоесть пункт 2.
Обернуть в объект стоит хотя бы ради вычисляемых полей, статического анализа кода IDE и рантаймовой проверки типов. Вообще мне странно как-то аргументировать необходимость ООП, это тема для отдельной дискуссии, не для ОРМ.
Мы не нарушаем ООП, если не преобразовываем документ в объект. Грубо говоря, мы получаем объект ПОТОКА данных и его пихаем в представление, целиком.
Разве что ради IDE абсолютно всегда делать объект, но это весьма спорный аргумент.
Не помню кто это сказал про самолеты и машины, что если пытаться сделать два в одном флаконе, то это будет либо плохой самолет, кторый будет относительно хорошо ездить по дорогам, либо плохой автомбиль, который сможет летать, но в большинстве случаев это будет просто плохолетающий херовый автомобиль.
Если посмотреть на базу данных с которой работало приложение с ОРМ, она больше всего напоминает минифицированый ж.скрипт. Т.е. оно вроде и рабочее, но пользоваться им без приложения уже нельзя.
Без орм будет не красиво.
Красиво было бы так:
$this->db->user->find($login)
$user->auth($password)
Вот такая вот она, пыховская инкапсуляция.
Иначе это тот самый кейс, про который я писал ниже: люди сначала завязывают всю систему на знание о БД, а потом не могут поменять конкретный вызов на SQL запрос (потому что пол системы надо перепахать) и делают вывод что ОРМ гумно
Звать все равно надо, так проще типа фильтра сделать.
По большом счету поле не совсем в базе, а через обертку.
Если уж там вам надо поле переименовать. Контракт останется контрактом, кто мешает переименовывать на уровне модели-то?
Будет много лучше.
Знаете, контракт:
findByLogin(string $login) куда понятнее контракта
find(array $hash)
:)
С остальной частью согласен.
я бы сказал инсерты
когда тебе надо вставить цепочку из кучи объектов - так и получится, хоть руками, хоть скрыть за орм
> Если посмотреть на базу данных с которой работало приложение с ОРМ, она больше всего напоминает минифицированый ж.скрипт
очевидно, стоит воспользоваться нормальной библиотекой ОРМ
который может задать кастомные названия таблиц, колонок, рассказать, где и как генерить генерируемое (если на бд вообще ничего не возлагается)
и всё, нормальный результат, нормальная база, которую не стыдно селектить и руками
единственно, орм обычно вместо того, чтобы использовать субдшно-зависимые фичи по генерации айдей, делают непотребщину, и в сгенеренную боевую базу на горячую иногда проблемно вставить новые строки со стороны (перед глазами пример одной системы, где единая последовательность для айди на почти все таблицы хранится в таблице sequences в строке с колонками key-value)
это цена за кросс-субдшность для бедных
Сначала я буду использовать ОРМ библиотеку, но буду задавать названия таблиц вручную. Потом я буду расписывать в паутине аннотаций как назвать "промежуточные таблицы", использующиеся для связи много-много. Потом в эту паутину из аннотаций будет вплетен почти такой же SQL как и настоящий, но с той разницей, что несколько названий таблиц в нем будут заменены на названия объектов к которым эти таблицы привязаны. Потом я пойму, что все равно и этого не хватает, и у меня будет:
1. Множество очень маленьких кусочков SQL выраженых как аннотации, равномерно распиханые по всему приложению.
2. Немного более кучно, но все же достаточно равномерно распиханые кусочки побольше с описанием запросов.
3. Несколько больших кусков, от отчаяния спрятаных куда подальше.
В итоге, у меня будет SQL програма написаная плохими инструментами, в неподходящем месте, которую нет возможности протестировать вне зависимости от другой програмы. По крайней мере это то, что мне доводилось видеть до сегодняшнего дня в Джанго и Хай-Бернейт.
В том же джанго все запросы принято писать в менеджере, и работать тоже через менеджер (это тамошний DAO). Все запросы лежат В ОДНОМ месте.
И многие виданные мною джанго-проекты были вполне себе сносны, чего не скажешь как раз о проектах без ORM, где было много бойлерплейтового кода который никогда не нужно было бы писать руками)
Кстати, недавно возился с sqlalchemy - так оно кучу проблем со вставкой пачки записей сняло. insert'ы и update'ы делает в правильном порядке, правильно юзает постгрешный serial (а не описанную выше срань с табличкой сиквенсов), само айдишки проставляет в ссылочные поля...
Генератор DDL по метаинфе неплохой: вставил serial'ы куда надо, типы правильно назвал, но, к сожалению, не умеет генерить alter'ы. А я так хотел считерить - заставить его сгенерить alter'ы и, если понадобится, допилить мелочи напильником :(
Мне кажется что когда-нибудь алчеми с джангой поженятся.
Я не ругаю родной джанговый ORM, ибо не юзал его ;)
Юзать джангу ради простенького REST сервачка, имхо, как забивать гвозди микроскопом.
Вот изучать джангу ради такого это имхо перебор
this
Ну вот у меня и сложилось впечатление соответствующее о том, что главная задача Джанго это затмить объемами все что можно затмить. Ну он и писался в такое время, когда всеобъемлющие фреймворки было очень модно писать. Сейчас мода прошла, но прифкус остался.
Вобщем, я пробовал и на Джанго простенький сервер (для тестов) и с Торнадо и с Твистед и просто BaseHTTPServer. В итоге, BaseHTTPServer всех победил в смысле минимализма и простоты. Никаких особых нагрузок там не предполагалось. Никаких настроек не требует. Тестеру отдал скрипт с запуском этого сервера + тестов для Селениума, и все довольны.
Посмотри еще flask. Тоже очень простенький интерфейс, но можно привязывать маршруты к функциям через аннотации декораторы.
Админка в джанге довольно неплохо конфигурится, и создает CRUD морду для типовых задач. Это гораздо лучше чем писать тоже самое вручную.
>> что главная задача Джанго это затмить объемами все что
можно затмить.
Это неправильное ощущение. Главные задачи Джанги (а так же рельсов в руби и иже с ними) это:
1) предоставить платформу для быстрого создания типовых приложений состоящих из БД, логики, подготовки вью и шаблонов., тоесть примерно для 80% приложений с вебмордой.
2) предоставить определенные архитектурные бест-практисы и конвенции, позволяющие легко разбираться с новыми приложениями, не думая каждый раз как они устроены
3) создать базу готовых решений. К джанге я могу подключить рич-текст поле, которое начнет отображаться как визивиг прямо в админке автоматом, могу подключить целый форум и он станет доступен по определнному мною урлу, начнет использовать мою базу, его статика автоматом будет собрана мне в нужное место, я смогу давать ссылки на этот форум из других мест системы не хардкодя урл итд.
>> всеобъемлющие фреймворки было очень модно писать
Модно было писать не фреймворки а CMSы.
Собственно, развивалось все так:
ПРОДОЛЖЕНИЕ СЛЕДУЕТ
Эра -1: ничего нет, каждый пишет как он слышит, гостевая книга на перле "guestbook.cgi" где шаблоны вперемешку с доступом к базе, на PHP SQL запросы лукаво прячутся среди HTML, форум отдельно, магазин отдельно, все между собой не совместимо, все допиливается руками, каждый форум, каждый магазин, все написано с ноля, разные шаблонизаторы, разные способы работы с БД, нет единой авторизации итд.
Эра 0: CMSы. Начали делать всякие друпалы и джумлы, но оказалось CMS хорош только для того чтоб показывать готовые странички, которые правят сотрудники. Внутри CMSа оказались зашиты такие понятия как "левая боковая панель", дизайн жестко привязан к CMS, переверстать ничерта нельзя, появились специальные "верстальщики с опытом верстки под джумлу", в итоге рядом с джумлой все равно стоит самопал и как-то вручную всё это дружат.
Наша эра: появились фреймворки (Zend, Cake, Django, Rails) где с одной стороны можно делать чего угодно, а с другой аут оф бокс ты получаешь какое-то количество функционала. Сейчас они активно используются и всё довольно хорошо.
>> BaseHTTPServer всех победил
Ну это примерно как сказать "пробовал я ваш MS Exchange, все таки sendmail лучше". Зачем Вы сравниваете HTTP сервер и фреймворк для создания веб-приложений с базой, шаблонами и прочими блек-джеками?
Думайте и Джанге как об Аксессе времен конца 90х: это способ БЫСТРО набросать базу и морду к ней. А потом допиливать.
Если Вам нужно один файл по HTTP отдать то да -- джанга Вам не нужна;)
Про BaseHTTPServer был комментарий bormand'у о личном опыте написания разовых веб-серверов без особых требований и желательно побыстрее. Где я неявно продвигаю мысль о том, что фреймворки, которые так долго говорили о том, как они сделают все проще для их пользователей, на самом деле не сделали все проще для пользователей.
ХЗ. Я не вижу какой-то хорошей области применения Джанго. Затраченые усилия не соответствуют результату. Он не освобождает от кропотливой и мучительно долгой работы над большими проектами и не очень-то уменьшает количество этой работы для маленьких проектов (особенно за счет настроек самого Джанго). Вот, Флекс тоже относится примерно к этой же эпохе, и во многих отношениях точно так же себя проявил. Маленькие приложения на нем делать бессмысленно т.как не хочется за собой тянуть почти четыре мегабайта фреймворка, ничего почти не сэкономив по времени на производство, а когда приложение вырастает до чего-то большего, оказывается что с фреймворком очень много проблем, и их решение занимает все свободное и внеурочное время.
2. Флекс это фреймоврк для создания гуи поверх флеша, и впринципе он был довольно хорош, но был убит HTML5, и поделом. Честно говоря я не понимаю как без флекса на флеше можно было делать GUI и что плохого в четырех мегабайтах.
3. Ну вот вам пример задачи под джанго. Есть список из ста товаров, товары могут относиться к одной или более категорий, нужно дать продавцу возможность быстро заполнять базу товарами, а покупатели могут их просматривать по категориям.
У Вас есть дизайн и верстка. На Джанго это делается примерно за пару часов. А что будете делать Вы?
Ну-ну. Живее всех живых в некоторых областях. Те же флеш-телефоны или видеостримы. Там вариантов просто нет. Емнип, они все с флексом.
Бедняга ютится в Adobe Air)
Кстати, у меня были коллеги которые довольно много писали на экшен скрипте под флекс. Они говорили что там хуёво всё начиная от документации, и кончая IDE на эклипсе.
---
Жаба аплеты тоже царствовали в вебе 1.0 (в то время на них даже кнопочки делали, прямо на свинге!)
А потом MS по требованию SUN выкинул JRE из стандартной поставки IE и аплеты сдулись.
Ну я только доводил до ума телефончик на флексе. IDE не юзал, правил обычным редактором, компилил скриптом из консольки.
Но подтверждаю. Хуёвость начинается с загрузки SDK под линь. Это был целый квест... Документация не айс, да. Но если сравнивать с "продуктами" типа джумлы - она хотя бы есть. И разобраться до уровня "доработать напильником, добавить своего говнеца с externalInterface и натянуть нарисованный коллегой дизайн" - оказалось вполне реально за пару дней. Но больше связываться с миром флеша\флекса что-то не хочется.
Вообще задавать можно, но работает как-то частично и не везде:
Нет, Флекс это не фреймворк для создания ГУЯ поверх Флеша. Во Флексе есть дофига всего и компилятор свой и какие-никакие инструменты для работы с SWF форматом, шаблонизатор (на базе Velocity), кодировщики, и работа с коллекциями и RPC и система оповещения о изменениях свойств объектов, и какие-то зачатки криптографии, и парсеры каких-то популярных форматов файлов, и это все идет в нагрузку к ГУЮ. Пример ГУИ фреймворка для Флеша - Старлинг.
Флекс всегда был говном, с самого его рождения и по сей день, но зато бесплатным. За что ему можно многое простить. Практически все, кто им пользовался жили с надеждой что не ровен час Адоби его существенно улучшат и перепишут с нуля.
ХТМЛ тут как бы не приделах, он находится с Флексом в ортогональной плоскости.
Последний вопрос: у вас есть ракетное топливо и один скафандр. На Байконуре это делается за секунды, а что будете делать вы?
Ну а о говёности я уже писал выше: все говорят что флекс говно, вот и Вы тоже так говорите)
Про Байконур: аналогия не совсем ясна. Байконур строить долго и дорого, а Джанго изучается за неделю. Устанавливается коммандой "pip install django". Поддерживается IDE (PyCharm, например). После этого у Вас есть инструмент для быстрого решения приведенной мною задачи.
Мне, все же, больше нравится определение педивикии:
[quote]
Apache Flex, formerly Adobe Flex, is a software development kit (SDK) for the development and deployment of cross-platform rich Internet applications based on the Adobe Flash platform.
[/quote]
ЗЫ. Я провел почти два года будучи в Adobe Flex Community Advisory Board, попал туда потому что помогал отвественному адобовцу с документацией фреймворка и немножко модерировал комментарии на разных адобовских форумах посвященных Флексу. Как бы, если есть вопросы про Флекс, то лучше верить мне, чем Википедии.
Хорошо, я буду Вам верить если мне вдруг придется столкнуться с флексом
Еще раз: у меня есть готовый HTML для вывода каких-то товаров из базы. Мне нужен движок который:
* Даст GUI для заполнения этой базы
* Выведет товары в приведенный верстуном HTML
Это классическая задача для обычного веба. Только в крупных проектах объектов не один (товар) а сто один, и страниц соответственно тоже сто один.
Джанго или нет, это может занять день или год. Откуда я знаю?
Чего именно не хватает Вам для оценки?
На всякий случай вот более развернутый вариант:
Категория состоит из ID и имени.
Товар состоит из ID, имени, одной или более фотографий, и цены.
Товар относится к одной или более категорий.
У юзера есть три экрана:
1) посмотреть все категории (название, ссылка)
2) посмотреть все товары в категории (название, первое фото, цена)
3) посмотреть страницу товара (список категорий, название, все фото)
Примерная посещаемость -- 10 человек в день.
Мне кажется информации достаточно для примерного выбора технологии, разве нет?
Так как бы Вы делали такой проект?) Использовали бы Django/Рельсы/WhatEver, или писали бы всё с ноля, включая формочку для загрузки картинок?
Использовали-бы Django ORM, или вручную написали бы SQL запросы для создания, поиска и удаления товаров и категорий?)
Делал один раз на Хексе, просто попробовать. Хз. не особо чет меня как-то порадовал он. Еще пробовал, например, попользоваться Нио в связке с Твистед. Плохая связка. Нио ни с чем хорошо кроме Явы не работает.
Ну и та же НодаЖС - как вариант, если на сервере совсем ничего делать не надо.
Допустим Вы выбрали скалу под JVM.
Дальше-то что будет?
Вы будете напрямую реализовывать интерфейс ?
Если это Скала, то наверно Лифт буду смотреть. Я не так чтобы сильно знаком. Наверное тупо скачал бы какой-нибудь маленький проект с Гитхаба и начал бы его перепиливать под то, что мне нужно.
Главное тут что Вы бы все таки взяли бы какой-нибудь фреймворк. Lift, например. Тоесть Вы не стали бы вручную реализовывать MVC, шаблонизатор итд.
Вы взяли бы фреймворк который это делает не смотря на массу кода, который он генерит) и даже не смотря на то, что Лифт имеет ОРМ:
http://demo.liftweb.net/database
Барабанная дробь: Джанго делает тоже самое!
Почему же Джанго не нужно, а Лифт нужен?
Если бы, например, выбросить из Джанго шаблоны, ОРМ и еще кучу всего, что мне не понадобится в хобби-проекте, то мне проще будет взять Торнадо вместо - меньше настроек, быстрее работает, меньше требований к пользовательскому коду.
Если мне нужно делать что-то более сложное, то это будет опять же уникальный проект, который, скорее всего будет пользоваться разными библиотеками для разных вещей, но они не будет библиотеками Джанго, потому что практически для всего, что может сделать Джанго есть лучшие альтернативы.
Не нравятся шаблоны -- не используйте. Не нравится ORM -- не используйте. Я правда не понимаю что в этом такого.
Тот факт что Вы опять упоминаете Торнадо который нужен для работы по HTTP а не для построения веб приложений говорит о том, что мы вернулись к тому, с чего начали. Торнадо Вам никак не поможет ни с шаблонизацией ни с БД ни с КРУД ни с чем. Это просто HTTP.
Ну и самое главное: в Вашем тексте Вы можете заменить слово "Django" на слово "Lift", и попытаться прочитать его снова;)
С Джанго, наоборот, получается ситуация, что если подписался на что-то одно, то вынужден использовать и остальное. Ну какой смысл делать сайт на Джанго а админку к нему не на Джанго? Это ж все равно что на зло водителю купить билет и пойти пешком.
ПС. Кроме того, у Джанго очень херовая документация. Не в смысле что ее мало, а в том слысле, что она очень безалаберно организована (т.е. вообще не организована никак). Просто найти класс или функцию которая должна делать что-то, что предположительно Джанго умеет делать - можно день потратить.
2. Смысл в том что Вы получаете бесплатно кучу всего, и можете использовать что Вам нужно. Открою страшную тайну: Свой CPU, свою OS и стандартную библиотеку своего языка Вы используете на 20%. Есть-ли смысл?
3. Документация? Вы сейчас точно про Джангу?
Там есть и гайд (который проходится за 3 часа и знакомит Вас с 80% возможностей джанги) и отличный референс
https://docs.djangoproject.com/en/1.7/contents/
У лифта же нет документации кроме видео (!) про геттинг стартед и кукбука (!!).
Мне кажется что дискуссию можно сворачивать) Выбор фреймворка это вопрос вкуса, и мне кажется что у Вас просто был bad experience в Джангой и потому Вы ее не любите (как вариант -- Скала нравится вам больше Пайтона, это логично)). В главном мы сошлись: какой-то фреймворк все-таки нужен. Не нужно руками писать SQL запросы, выводить HTML через писание в поток, и в конце концов не нужно делать вот так: http://govnokod.ru/17083
А код без фреймворка практически всегда именно так и выглядет
>шаблоны, ОРМ и еще кучу всего, что мне не понадобится в хобби-проекте
то проще взять изкоробочный htppserver или сразу пхп?
Хотя джанга для начала действительно сложновата.
лично я, если для товарища - взял бы говнобитрикс или оскомерс... уж точно не джангу, чтоб он меня потом проклинал ища питонистов... ну хоть не лисперов...
Насчет задачи. Кроме как вывести это все, потом ведь заказчик захочет корзину, фильтры и поиск... и придем к тому, о чем говорил wvxvw...
Саму задачу и на вермешелекоде с копипастами можно за день наколбасить - вопрос поддержки. Собственно, что и с джангой.
2) Любой CMS в известной степени ограничивает. Есть определенный шанс на то, что НЕ ЛЮБУЮ верстку можно натянуть на битрикс.
3) Давайте вопросы рынка вынесем за пределы: считайте что поддерживать его будете Вы. Тот факт что пыховой школоты (кстати, не факт что школота умеет битрикс) куда больше чем питонячей к вопросу наличия фреймворка отношения не имеет.
4) Конечно он потом захочет корзину, форум, и черта лысого в ступе.
5) На вермешель коде можно заколбасить за день, и потом получить XSS, SQL Injection, неподдерживаемый код и потраченный день. На джанге можно сделать поддерживаемо, безопасно и за несколько часов.
Речь тут не о джанге как таковой, а о выборе фреймворка в целом.
Товарищ сказал что они не нужны. В итоге мы договорились до того, что он взял бы Lift. Тоесть он признал таки необходимость наличия фреймворка.
Вы тоже предложили фреймворк, правда вместе с CMS, тоесть все ж таки косвенно подтвердили мои слова:)
Битрикс - относительно платен. Доступен любому мелкому ИП, всяко меньше, чем прогерам платить. Шаблон можно любой натянуть. Там фактически таже вермишель в шаблонах, только доступ к базе через обертку.
Вы выступили с задачей без контекста.
Можно решить втупую, а можно задуматься о дальнейшем развитии. Вот тут и начинаем подбирать не фреймворк, а инструмент вцелом.
Вопрос как проект будет развиваться - от этого будет зависеть и выбор. Если вы знаете джангу, и подписались поддерживать проект - то должны взять именно ее, об чем может быть вообще тут спор?
Дело тут не в Джанге: с таким же успехом можно говорить о рейлс, или грейлс, или плее или cakephp итд. Важно что есть некий фреймворк который решает типовые задачи из которых такой сайт состоит чуть менее, чем полностью:)
Конечно же в серьезном проекте надо писать много своего кода. Но это не повод вручную реализовывать защиту от XSS или формочку для загрузки картинки:)
Так категорично говорить нельзя. В целом у нас вообще только один критерий: don't repeat yourself. Следуя ему товарищ либо в итоге возмет подходящий фреймворк либо напишет свой... Накладные расходы? Зависит от задачи.
Они тоже не понимали зачем писать на си, а потом переписывать вручую боттлнеки (компиляторы тогда были тупые).
А потом они поняли что переписать надо только 20%. Закон Парето тоже.
Тоже самое с ORM.
Типовой проект с вебмордой на 80% состоит из тупых формочек и круда которые отлично покрываются типовым фреймворком.
Горячие места можно переписать вручную. Достаточно гибкие ОРМы это позволяют.
Распихано? - сужу по опыту Хай-бернейта. Классы с его аннотациями как правило встречаются равномерно во всем приложении. В Джанго как бы тоже может быть много контроллеров, распиханых где угодно. Когда я смотрю в наш проект на Джанго, я как бы даже вообще не представляю почему кому-то когда-то в голову пришла мысль поместить этот класс модели в это конкретное место. И почему он так а не по-другому работает с базой данных.
Наши еще вообще молодцы. Они решили поиск написать с использованием ОРМ. Т.е. поиск не просто подстроки, а с синонимами, контекстом и исправлением ошибок. Т.е. как бы назначение базы данных в первую очередь обеспечить хранение и быстрый доступ, но когда ее исползуют именно для этого через ОРМ оказывается что ОРМ не решает никаких проблем, но создает кучу. В итоге потому что наши питонисты нихера не понимают в Сиквеле, поиск таки работает с ОРМ. Херня полнейшая, дикие тормоза и результаты не выдерживают никакой критики.
Архитектуры всегда ужасные. Это нужно принимать за базовую оценку. При оценке чего-то нужно исходить из того, что архитектура будет херовой. Что программисты будут нубами, леняями и т.д. Иначе, если оптимизировать условия, а не решения, можно просто захерачить в код одну универсальную константу, и сказать, что идеал достигнут.
2, Вы (да и не только Вы) немного путаете два вопроса:
* Использование/НЕ использование ORM
* Вынос database-specific code в отдельный layer.
К сожалению большинство людей думает что если это ORM а не голый SQL, то можно пихать код прямо в контроллеры или вьюхи (отсюда аннотации хибера, распиханные по всему коду). Тоесть вхерачить SQL во вью не рискнет никто кроме совсем уж нуба, а вот вхерачить ORM запрос -- влегкую! Это же java (или python, или c#, what ever). На самом деле это ТАК ЖЕ плохо как и голый SQL.
В том же джанго есть довольно внятная архитектура с бест-практисами: это тяжелые модели с бизнес API, в которых спрятаны запросы к базе. Хочешь -- в SQL. Хочешь -- в ORM. Без разницы.
Если у Ваших коллег "много контроллеров, распиханных как угодно" значит они просто не знают что контроллеры живут во views.py :) Отсюда и проблемы, а вовсе не из ORM.
Еще раз:
Работать с БД надо ТОЛЬКО через уровень менеджеров джанги (он же сервис леер в нормальной терминологии).
Тоесть:
users = User.get_very_heavy_data(42)
Внутри метода get_very_heavy_data может быть сложный ORM запрос, который пишется за 15 секунд. Когда в базе появляется 144 пользователя, он начинает тормозить и тогда Вы просто выкидываете его и пишите запрос на голом SQL с использованием особенностей постгри (или что там у вас).
Остальная часть системы не страдает.
Если же конечно ORM запросы встречаются у вас во вью, в шаблонах, и вообще везде, то это конечно ужасный рак, и вот от такого действительно страдают многие приложения.
>>коллекции равнозначны и мапятся в один и тот же класс
Не всегда. В крупных системах можно встретить наследование)
>> Грубо говоря, мы получаем объект ПОТОКА данных и его пихаем в представление, целиком.
Если все поля документа равнозначны то да, мы ничего не нарушаем.
Если же мы хардкодим в шаблоне знание о том что по ключу foo лежит int, а по ключу bar -- float, то это уже не так хорошо.
<ul>
{% for item in items %}
<li><a href="{{ item.href }}">{{ item.title }}</a></li>
{% endfor %}
</ul>
Вот какая разница - item это объект или ассоциативный массив?
Просто иногда шаблон хочет форматировать даты, например.
И тогда ему важно знать что в поле birthday лежит дата.
Другой вариант это Ящик Пандоры в шаблонах:
Хотя конечно в идеальном мире всё это должно хендлится уровнем выше (во вьюшках в терминах джанги например) и в шаблонизатор может смело приезжать string-string.
Но опять же: где-то же должны эти преобразования происходить. Если не в модели, то во вьюхе. Ну а худые модели и толстые вьюхи/контроллеры все равно приведут к копи-пасте
Вьюха тут должна хардкодить однозначно. Вьюху вы передаете верстальщику - это его дело, как дату представлять.
ну короче в шаблон передаем чистую дату, не стринг, я это имел ввиду.
А уровнем выше вьюху стараемся как можно меньше трогать вообще, лучше никогда.
То есть мы должны выводить поля автоматически. Когда мы в шаблоне точно знаем че как - это один кейс, а когда автоматически - все немного по-другому... но и в этом случае как таковой орм не является необходимым.
Думаю вот как-то так выводим автоматическую форму (примитивно, конечно):
где input - это колбэк (живет скорее всего во вьюхе, как у вас в терминах пытхона, ну или в контроллере), он по переданным параметра генерит хтмл с нужным инпутом (пихает параметры в нужный шаблон для инпута и отдает отрендеренный результат).
properties - могут быть сгенерированы впринципе автоматом из модели (по дефолту) и пофичены во вьюхе или контроллере, а могут и в базе лежать, как метданные. В любом случае и для метаданных орм не является необходимым.
И еще заметьте одну штуку. Типы полей в базе - это не одно и тоже, что типы полей на форме, они не всегда мапятся один-в-один.
Long Sleeve Geometric Print Chiffon Blouse
Long Sleeve Geometric Print Chiffon Blouse
https://lenkmio.com/g/2316b8f856c30691751022af2ed61b/?i=5&ulp=http%3A%2F%2Fwww.gearbest.c om%2Fblouses%2Fpp_546792.html - http://gloimg.gearbest.com/gb/pdm-product-pic/Clothing/2016/10/28/goods-img/1478122791457084660.jpg
10.14 USD
https://lenkmio.com/g/2316b8f856c30691751022af2ed61b/?i=5&ulp=http%3A%2F%2Fwww.gearbest.c om%2Fblouses%2Fpp_546792.html - https://www.jackcarcare.com/images/buyNow.png
GB:#66ddedsagKUYUF#
http://osvoim-forex.ru/httpforum-osvoim-forex-ruindex-php/#comment-501 - Women's Stylish Scoop Neck Long Sleeve Leopard Plus Size Dress
http://borzoi-bic.ru/forum/index.php?showuser=8869 - Pullover Graphic Printed Hoodie
https://leftfootforward.org/2016/10/theresa-mays-snoopers-charter-is-a-death-sentence-for-investigative-journalism/ - Slim Fit Zipper Fly Distressed Jeans
http://o.kr.ua/ru/chto_skryvayut_zhenshhiny._nacionalnyj_f orum_zhenshhiny_za_mir_v_krivom_roge_pro shel_v_obstanovke_strogoj_sekretnosti.ht ml - Single Breasted Epaulet Embellished Wind Coat
http://sweet-heart.dir.bg/_wm/mp3/?df=103020&GDirId=4950c432821c5aa3bdf8ee 0d54732ce7 - Long Sleeve Plus Size Mini Flare Dress
На страницах Интернет-магазина вы сможете найти парсеры и грабберы для Интернет-торговли, приобрести информацию с базами контактов и e-mail. <a href=http://parsinfo.ru/products/email-adresa-volgogradskaya-oblast-dubovki>адреса жителей дубовка</a>. Мы предлагаем даже базы сайтов и устойчивые SMTP серверы для отсылки e-mail сообщений.
Наши программы и базы данных смогут вам помочь в вашем бизнесе! <a href=http://parsinfo.ru/catalog/krasnodarskij-kraj>база даных людеи г краснодара</a>. Они созданы для того, дабы дефрагментировать информацию для её наиболее эффективного применения. Такой подход к делу даёт возможность заниматься Интернет-маркетингом в несколько раз эффективнее и зарабатывая соответственно в несколько раз больше денег. А базы сайтов и e-mail позволят всегда иметь полный список постоянных и потенциальных клиентов, держать связь и поддерживать сотрудничество, договариваться и оформлять сделки.
Для каждого пользователя мы предлагаем бесплатный парсер e-mail с сайтов, остальное ПО и базы контактов и данных мы предлагаем вам по низкой цене. <a href=http://parsinfo.ru/products/smtp-servera-dlya-rassylki>smtp сервер аренда для рассылки</a>. Вложенные данным образом средства помогут повысить вашу прибыль на порядок!