- 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;
}
}
?>
Мой шаблонизатор. Детям и беременным женщинам не смотреть.
Анонимус 05.11.2014 22:03 # 0
Efog 05.11.2014 22:06 # 0
Анонимус 05.11.2014 22:11 # +1
Их мало?
Efog 05.11.2014 22:12 # +3
Анонимус 05.11.2014 22:14 # 0
Нужно всегда написать свои ООП обертки для коллекций, свой шаблонизатор, свой CMS , свой форум и свою социальную сеть.
Efog 05.11.2014 22:15 # +2
Анонимус 05.11.2014 22:17 # 0
Efog 05.11.2014 22:19 # 0
Анонимус 05.11.2014 22:22 # 0
удачи!
Efog 05.11.2014 22:23 # +1
defecate-plusplus 05.11.2014 22:24 # +3
Efog 05.11.2014 22:25 # 0
defecate-plusplus 05.11.2014 22:32 # +1
на деле же даже jpa и прочий хайбернейт посасывают в заметной части случаев у обычных нативных запросов
Efog 05.11.2014 22:34 # 0
Вот, в моих ГК есть запрос с группировкой, пол часа с ним еб*лся, хотя вроде и можно как-то проще сделать.
defecate-plusplus 05.11.2014 23:20 # 0
даже для mysql есть несколько способов в рамках общих правил sql
и даже без единого group by
defecate-plusplus 05.11.2014 23:30 # +1
bormand 05.11.2014 23:35 # +2
defecate-plusplus 06.11.2014 11:48 # +1
не только в мускуле собсно
http://sqlfiddle.com/#!4/769c4/1
это просто был пример решения без групп бабайки
bormand 05.11.2014 23:13 # 0
Анонимус 05.11.2014 23:22 # 0
doo_dee_doo_dmt 06.11.2014 16:38 # 0
орм нужен для инкапсуляции поведения. Из базы вычитываем параметры объекта и вызываем методы, которые у себя внутри используют эти параметры. Получается универсальность. Сохранение объектом самого себя (по айди например) - как одно из инкапсулированных действий.
Анонимус 06.11.2014 16:44 # 0
Остальную часть не очень понял, но инкапсуляция это безусловно один из плюсов ОРМ.
Итого плюсы орм:
1) собственно OR/M: маппинг кучи полей объекта в поля таблицы (и наоборот)
2) динамическое построение запросов в терминах объекта а не базы
3) кеш
4) в легких случаях относительная бд независимость
5) ну всякие плюшки вроде физической невозможности SQL injection и прочей херни
6) легкий CRUD аут оф бокс
doo_dee_doo_dmt 06.11.2014 16:54 # 0
3 - кэш тоже не часть орм, и тоже проще даже делать его на уровне всей коллекции
2 - динамическое построение запросов... ну это если sql, но орм имеет смысл и для nosql.
только 1 и есть - орм.
но тут не перечислено еще то, что какие-нибудь свойства объекта можно посчитать/преобразовать налету.
Насчет как сделать круд без преобразования в объект: ну пишем класс для всей коллекции в котором будут методы create, read, update, delete - не вижу проблем. Минус только в том что при сохранении нужно будет всегда таскать айдишник, но тут зависит от задачи. Если вы этот айдишник и так получили от юзера - че бы его и не пихнуть.
Анонимус 06.11.2014 17:01 # 0
Большинство ОРМ умеют 1 и 2 (ну кроме майбатиса). Верно?
Тоесть человек или берет фреймворк с 1 и 2, или пишет SQL запросы руками и руками-же мапит результаты в объекты (ну мы же говорим об ООП).
И вот у человека есть шесть таблиц, в каждой по 15 полей. Без 1 и 2 ему нужно будет написать 4 * 6 тупых SQL запросов и 15 * 6 вызовов мутатора или установки значения в поле объекта.
Вот собссно про это я и говорил.
doo_dee_doo_dmt 06.11.2014 17:26 # 0
Я не против ОРМ, а за, но оно не 100% панацея ото всего. Иногда оно может и мешать. Я считаю ОРМ должно быть включаемым/выключаемым от задачи, от уровня необходимой инкапсуляции.
Круд как таковой не требует преобразования в объект (при равном количестве кода).
Вы же данные все равно в шаблонизатор пихнете - какая разница объекты там или ассоциативные массивы. Зачем накладные расходы?
Анонимус 06.11.2014 17:34 # 0
Тоесть пункт 2.
Обернуть в объект стоит хотя бы ради вычисляемых полей, статического анализа кода IDE и рантаймовой проверки типов. Вообще мне странно как-то аргументировать необходимость ООП, это тема для отдельной дискуссии, не для ОРМ.
doo_dee_doo_dmt 06.11.2014 17:53 # 0
Мы не нарушаем ООП, если не преобразовываем документ в объект. Грубо говоря, мы получаем объект ПОТОКА данных и его пихаем в представление, целиком.
Разве что ради IDE абсолютно всегда делать объект, но это весьма спорный аргумент.
wvxvw 06.11.2014 18:38 # 0
Не помню кто это сказал про самолеты и машины, что если пытаться сделать два в одном флаконе, то это будет либо плохой самолет, кторый будет относительно хорошо ездить по дорогам, либо плохой автомбиль, который сможет летать, но в большинстве случаев это будет просто плохолетающий херовый автомобиль.
Если посмотреть на базу данных с которой работало приложение с ОРМ, она больше всего напоминает минифицированый ж.скрипт. Т.е. оно вроде и рабочее, но пользоваться им без приложения уже нельзя.
doo_dee_doo_dmt 06.11.2014 18:53 # +1
Без орм будет не красиво.
Анонимус 06.11.2014 19:58 # 0
Красиво было бы так:
$this->db->user->find($login)
$user->auth($password)
doo_dee_doo_dmt 06.11.2014 22:22 # 0
Анонимус 06.11.2014 22:25 # 0
bormand 06.11.2014 22:27 # 0
Вот такая вот она, пыховская инкапсуляция.
Анонимус 06.11.2014 22:32 # 0
Иначе это тот самый кейс, про который я писал ниже: люди сначала завязывают всю систему на знание о БД, а потом не могут поменять конкретный вызов на SQL запрос (потому что пол системы надо перепахать) и делают вывод что ОРМ гумно
doo_dee_doo_dmt 06.11.2014 23:15 # 0
Звать все равно надо, так проще типа фильтра сделать.
По большом счету поле не совсем в базе, а через обертку.
Если уж там вам надо поле переименовать. Контракт останется контрактом, кто мешает переименовывать на уровне модели-то?
Анонимус 06.11.2014 23:19 # +2
Будет много лучше.
Знаете, контракт:
findByLogin(string $login) куда понятнее контракта
find(array $hash)
:)
С остальной частью согласен.
doo_dee_doo_dmt 07.11.2014 00:04 # +1
defecate-plusplus 06.11.2014 18:54 # +2
я бы сказал инсерты
когда тебе надо вставить цепочку из кучи объектов - так и получится, хоть руками, хоть скрыть за орм
> Если посмотреть на базу данных с которой работало приложение с ОРМ, она больше всего напоминает минифицированый ж.скрипт
очевидно, стоит воспользоваться нормальной библиотекой ОРМ
который может задать кастомные названия таблиц, колонок, рассказать, где и как генерить генерируемое (если на бд вообще ничего не возлагается)
и всё, нормальный результат, нормальная база, которую не стыдно селектить и руками
единственно, орм обычно вместо того, чтобы использовать субдшно-зависимые фичи по генерации айдей, делают непотребщину, и в сгенеренную боевую базу на горячую иногда проблемно вставить новые строки со стороны (перед глазами пример одной системы, где единая последовательность для айди на почти все таблицы хранится в таблице sequences в строке с колонками key-value)
это цена за кросс-субдшность для бедных
wvxvw 06.11.2014 19:18 # 0
Сначала я буду использовать ОРМ библиотеку, но буду задавать названия таблиц вручную. Потом я буду расписывать в паутине аннотаций как назвать "промежуточные таблицы", использующиеся для связи много-много. Потом в эту паутину из аннотаций будет вплетен почти такой же SQL как и настоящий, но с той разницей, что несколько названий таблиц в нем будут заменены на названия объектов к которым эти таблицы привязаны. Потом я пойму, что все равно и этого не хватает, и у меня будет:
1. Множество очень маленьких кусочков SQL выраженых как аннотации, равномерно распиханые по всему приложению.
2. Немного более кучно, но все же достаточно равномерно распиханые кусочки побольше с описанием запросов.
3. Несколько больших кусков, от отчаяния спрятаных куда подальше.
В итоге, у меня будет SQL програма написаная плохими инструментами, в неподходящем месте, которую нет возможности протестировать вне зависимости от другой програмы. По крайней мере это то, что мне доводилось видеть до сегодняшнего дня в Джанго и Хай-Бернейт.
doo_dee_doo_dmt 06.11.2014 19:29 # 0
Анонимус 06.11.2014 20:05 # 0
В том же джанго все запросы принято писать в менеджере, и работать тоже через менеджер (это тамошний DAO). Все запросы лежат В ОДНОМ месте.
И многие виданные мною джанго-проекты были вполне себе сносны, чего не скажешь как раз о проектах без ORM, где было много бойлерплейтового кода который никогда не нужно было бы писать руками)
bormand 06.11.2014 20:15 # 0
Кстати, недавно возился с sqlalchemy - так оно кучу проблем со вставкой пачки записей сняло. insert'ы и update'ы делает в правильном порядке, правильно юзает постгрешный serial (а не описанную выше срань с табличкой сиквенсов), само айдишки проставляет в ссылочные поля...
Генератор DDL по метаинфе неплохой: вставил serial'ы куда надо, типы правильно назвал, но, к сожалению, не умеет генерить alter'ы. А я так хотел считерить - заставить его сгенерить alter'ы и, если понадобится, допилить мелочи напильником :(
Анонимус 06.11.2014 20:50 # 0
Мне кажется что когда-нибудь алчеми с джангой поженятся.
bormand 06.11.2014 20:55 # 0
Я не ругаю родной джанговый ORM, ибо не юзал его ;)
Юзать джангу ради простенького REST сервачка, имхо, как забивать гвозди микроскопом.
Анонимус 06.11.2014 21:23 # +1
Вот изучать джангу ради такого это имхо перебор
bormand 06.11.2014 22:15 # 0
this
wvxvw 07.11.2014 02:18 # 0
Ну вот у меня и сложилось впечатление соответствующее о том, что главная задача Джанго это затмить объемами все что можно затмить. Ну он и писался в такое время, когда всеобъемлющие фреймворки было очень модно писать. Сейчас мода прошла, но прифкус остался.
Вобщем, я пробовал и на Джанго простенький сервер (для тестов) и с Торнадо и с Твистед и просто BaseHTTPServer. В итоге, BaseHTTPServer всех победил в смысле минимализма и простоты. Никаких особых нагрузок там не предполагалось. Никаких настроек не требует. Тестеру отдал скрипт с запуском этого сервера + тестов для Селениума, и все довольны.
bormand 07.11.2014 06:16 # 0
Посмотри еще flask. Тоже очень простенький интерфейс, но можно привязывать маршруты к функциям через аннотации декораторы.
Анонимус 07.11.2014 19:18 # 0
Админка в джанге довольно неплохо конфигурится, и создает CRUD морду для типовых задач. Это гораздо лучше чем писать тоже самое вручную.
>> что главная задача Джанго это затмить объемами все что
можно затмить.
Это неправильное ощущение. Главные задачи Джанги (а так же рельсов в руби и иже с ними) это:
1) предоставить платформу для быстрого создания типовых приложений состоящих из БД, логики, подготовки вью и шаблонов., тоесть примерно для 80% приложений с вебмордой.
2) предоставить определенные архитектурные бест-практисы и конвенции, позволяющие легко разбираться с новыми приложениями, не думая каждый раз как они устроены
3) создать базу готовых решений. К джанге я могу подключить рич-текст поле, которое начнет отображаться как визивиг прямо в админке автоматом, могу подключить целый форум и он станет доступен по определнному мною урлу, начнет использовать мою базу, его статика автоматом будет собрана мне в нужное место, я смогу давать ссылки на этот форум из других мест системы не хардкодя урл итд.
>> всеобъемлющие фреймворки было очень модно писать
Модно было писать не фреймворки а CMSы.
Собственно, развивалось все так:
ПРОДОЛЖЕНИЕ СЛЕДУЕТ
Анонимус 07.11.2014 19:18 # 0
Эра -1: ничего нет, каждый пишет как он слышит, гостевая книга на перле "guestbook.cgi" где шаблоны вперемешку с доступом к базе, на PHP SQL запросы лукаво прячутся среди HTML, форум отдельно, магазин отдельно, все между собой не совместимо, все допиливается руками, каждый форум, каждый магазин, все написано с ноля, разные шаблонизаторы, разные способы работы с БД, нет единой авторизации итд.
Эра 0: CMSы. Начали делать всякие друпалы и джумлы, но оказалось CMS хорош только для того чтоб показывать готовые странички, которые правят сотрудники. Внутри CMSа оказались зашиты такие понятия как "левая боковая панель", дизайн жестко привязан к CMS, переверстать ничерта нельзя, появились специальные "верстальщики с опытом верстки под джумлу", в итоге рядом с джумлой все равно стоит самопал и как-то вручную всё это дружат.
Наша эра: появились фреймворки (Zend, Cake, Django, Rails) где с одной стороны можно делать чего угодно, а с другой аут оф бокс ты получаешь какое-то количество функционала. Сейчас они активно используются и всё довольно хорошо.
>> BaseHTTPServer всех победил
Ну это примерно как сказать "пробовал я ваш MS Exchange, все таки sendmail лучше". Зачем Вы сравниваете HTTP сервер и фреймворк для создания веб-приложений с базой, шаблонами и прочими блек-джеками?
Думайте и Джанге как об Аксессе времен конца 90х: это способ БЫСТРО набросать базу и морду к ней. А потом допиливать.
Если Вам нужно один файл по HTTP отдать то да -- джанга Вам не нужна;)
wvxvw 07.11.2014 20:37 # 0
Про BaseHTTPServer был комментарий bormand'у о личном опыте написания разовых веб-серверов без особых требований и желательно побыстрее. Где я неявно продвигаю мысль о том, что фреймворки, которые так долго говорили о том, как они сделают все проще для их пользователей, на самом деле не сделали все проще для пользователей.
ХЗ. Я не вижу какой-то хорошей области применения Джанго. Затраченые усилия не соответствуют результату. Он не освобождает от кропотливой и мучительно долгой работы над большими проектами и не очень-то уменьшает количество этой работы для маленьких проектов (особенно за счет настроек самого Джанго). Вот, Флекс тоже относится примерно к этой же эпохе, и во многих отношениях точно так же себя проявил. Маленькие приложения на нем делать бессмысленно т.как не хочется за собой тянуть почти четыре мегабайта фреймворка, ничего почти не сэкономив по времени на производство, а когда приложение вырастает до чего-то большего, оказывается что с фреймворком очень много проблем, и их решение занимает все свободное и внеурочное время.
Анонимус 07.11.2014 20:43 # 0
2. Флекс это фреймоврк для создания гуи поверх флеша, и впринципе он был довольно хорош, но был убит HTML5, и поделом. Честно говоря я не понимаю как без флекса на флеше можно было делать GUI и что плохого в четырех мегабайтах.
3. Ну вот вам пример задачи под джанго. Есть список из ста товаров, товары могут относиться к одной или более категорий, нужно дать продавцу возможность быстро заполнять базу товарами, а покупатели могут их просматривать по категориям.
У Вас есть дизайн и верстка. На Джанго это делается примерно за пару часов. А что будете делать Вы?
bormand 07.11.2014 20:47 # 0
Ну-ну. Живее всех живых в некоторых областях. Те же флеш-телефоны или видеостримы. Там вариантов просто нет. Емнип, они все с флексом.
Анонимус 07.11.2014 20:52 # 0
Бедняга ютится в Adobe Air)
Кстати, у меня были коллеги которые довольно много писали на экшен скрипте под флекс. Они говорили что там хуёво всё начиная от документации, и кончая IDE на эклипсе.
---
Жаба аплеты тоже царствовали в вебе 1.0 (в то время на них даже кнопочки делали, прямо на свинге!)
А потом MS по требованию SUN выкинул JRE из стандартной поставки IE и аплеты сдулись.
bormand 07.11.2014 20:56 # 0
Ну я только доводил до ума телефончик на флексе. IDE не юзал, правил обычным редактором, компилил скриптом из консольки.
Но подтверждаю. Хуёвость начинается с загрузки SDK под линь. Это был целый квест... Документация не айс, да. Но если сравнивать с "продуктами" типа джумлы - она хотя бы есть. И разобраться до уровня "доработать напильником, добавить своего говнеца с externalInterface и натянуть нарисованный коллегой дизайн" - оказалось вполне реально за пару дней. Но больше связываться с миром флеша\флекса что-то не хочется.
Анонимус 07.11.2014 21:01 # 0
bormand 07.11.2014 21:00 # 0
Анонимус 07.11.2014 21:09 # 0
Вообще задавать можно, но работает как-то частично и не везде:
wvxvw 07.11.2014 20:59 # 0
Нет, Флекс это не фреймворк для создания ГУЯ поверх Флеша. Во Флексе есть дофига всего и компилятор свой и какие-никакие инструменты для работы с SWF форматом, шаблонизатор (на базе Velocity), кодировщики, и работа с коллекциями и RPC и система оповещения о изменениях свойств объектов, и какие-то зачатки криптографии, и парсеры каких-то популярных форматов файлов, и это все идет в нагрузку к ГУЮ. Пример ГУИ фреймворка для Флеша - Старлинг.
Флекс всегда был говном, с самого его рождения и по сей день, но зато бесплатным. За что ему можно многое простить. Практически все, кто им пользовался жили с надеждой что не ровен час Адоби его существенно улучшат и перепишут с нуля.
ХТМЛ тут как бы не приделах, он находится с Флексом в ортогональной плоскости.
Последний вопрос: у вас есть ракетное топливо и один скафандр. На Байконуре это делается за секунды, а что будете делать вы?
Анонимус 07.11.2014 21:05 # 0
Ну а о говёности я уже писал выше: все говорят что флекс говно, вот и Вы тоже так говорите)
Про Байконур: аналогия не совсем ясна. Байконур строить долго и дорого, а Джанго изучается за неделю. Устанавливается коммандой "pip install django". Поддерживается IDE (PyCharm, например). После этого у Вас есть инструмент для быстрого решения приведенной мною задачи.
wvxvw 07.11.2014 21:06 # 0
Анонимус 07.11.2014 21:11 # 0
Мне, все же, больше нравится определение педивикии:
[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]
wvxvw 07.11.2014 21:15 # +1
ЗЫ. Я провел почти два года будучи в Adobe Flex Community Advisory Board, попал туда потому что помогал отвественному адобовцу с документацией фреймворка и немножко модерировал комментарии на разных адобовских форумах посвященных Флексу. Как бы, если есть вопросы про Флекс, то лучше верить мне, чем Википедии.
Анонимус 07.11.2014 21:16 # 0
Хорошо, я буду Вам верить если мне вдруг придется столкнуться с флексом
wvxvw 07.11.2014 21:11 # 0
Анонимус 07.11.2014 21:14 # 0
Еще раз: у меня есть готовый HTML для вывода каких-то товаров из базы. Мне нужен движок который:
* Даст GUI для заполнения этой базы
* Выведет товары в приведенный верстуном HTML
Это классическая задача для обычного веба. Только в крупных проектах объектов не один (товар) а сто один, и страниц соответственно тоже сто один.
wvxvw 07.11.2014 21:18 # 0
Джанго или нет, это может занять день или год. Откуда я знаю?
Анонимус 07.11.2014 21:24 # 0
Чего именно не хватает Вам для оценки?
На всякий случай вот более развернутый вариант:
Категория состоит из ID и имени.
Товар состоит из ID, имени, одной или более фотографий, и цены.
Товар относится к одной или более категорий.
У юзера есть три экрана:
1) посмотреть все категории (название, ссылка)
2) посмотреть все товары в категории (название, первое фото, цена)
3) посмотреть страницу товара (список категорий, название, все фото)
Примерная посещаемость -- 10 человек в день.
Мне кажется информации достаточно для примерного выбора технологии, разве нет?
wvxvw 07.11.2014 21:30 # 0
Анонимус 07.11.2014 21:34 # 0
Так как бы Вы делали такой проект?) Использовали бы Django/Рельсы/WhatEver, или писали бы всё с ноля, включая формочку для загрузки картинок?
Использовали-бы Django ORM, или вручную написали бы SQL запросы для создания, поиска и удаления товаров и категорий?)
wvxvw 07.11.2014 23:13 # 0
Делал один раз на Хексе, просто попробовать. Хз. не особо чет меня как-то порадовал он. Еще пробовал, например, попользоваться Нио в связке с Твистед. Плохая связка. Нио ни с чем хорошо кроме Явы не работает.
Ну и та же НодаЖС - как вариант, если на сервере совсем ничего делать не надо.
Анонимус 07.11.2014 23:23 # 0
Допустим Вы выбрали скалу под JVM.
Дальше-то что будет?
Вы будете напрямую реализовывать интерфейс ?
wvxvw 07.11.2014 23:40 # 0
Если это Скала, то наверно Лифт буду смотреть. Я не так чтобы сильно знаком. Наверное тупо скачал бы какой-нибудь маленький проект с Гитхаба и начал бы его перепиливать под то, что мне нужно.
Анонимус 07.11.2014 23:55 # 0
Главное тут что Вы бы все таки взяли бы какой-нибудь фреймворк. Lift, например. Тоесть Вы не стали бы вручную реализовывать MVC, шаблонизатор итд.
Вы взяли бы фреймворк который это делает не смотря на массу кода, который он генерит) и даже не смотря на то, что Лифт имеет ОРМ:
http://demo.liftweb.net/database
Барабанная дробь: Джанго делает тоже самое!
Почему же Джанго не нужно, а Лифт нужен?
wvxvw 08.11.2014 00:07 # 0
Если бы, например, выбросить из Джанго шаблоны, ОРМ и еще кучу всего, что мне не понадобится в хобби-проекте, то мне проще будет взять Торнадо вместо - меньше настроек, быстрее работает, меньше требований к пользовательскому коду.
Если мне нужно делать что-то более сложное, то это будет опять же уникальный проект, который, скорее всего будет пользоваться разными библиотеками для разных вещей, но они не будет библиотеками Джанго, потому что практически для всего, что может сделать Джанго есть лучшие альтернативы.
Анонимус 08.11.2014 00:13 # 0
Не нравятся шаблоны -- не используйте. Не нравится ORM -- не используйте. Я правда не понимаю что в этом такого.
Тот факт что Вы опять упоминаете Торнадо который нужен для работы по HTTP а не для построения веб приложений говорит о том, что мы вернулись к тому, с чего начали. Торнадо Вам никак не поможет ни с шаблонизацией ни с БД ни с КРУД ни с чем. Это просто HTTP.
Ну и самое главное: в Вашем тексте Вы можете заменить слово "Django" на слово "Lift", и попытаться прочитать его снова;)
wvxvw 08.11.2014 01:42 # 0
С Джанго, наоборот, получается ситуация, что если подписался на что-то одно, то вынужден использовать и остальное. Ну какой смысл делать сайт на Джанго а админку к нему не на Джанго? Это ж все равно что на зло водителю купить билет и пойти пешком.
ПС. Кроме того, у Джанго очень херовая документация. Не в смысле что ее мало, а в том слысле, что она очень безалаберно организована (т.е. вообще не организована никак). Просто найти класс или функцию которая должна делать что-то, что предположительно Джанго умеет делать - можно день потратить.
Анонимус 09.11.2014 02:18 # 0
2. Смысл в том что Вы получаете бесплатно кучу всего, и можете использовать что Вам нужно. Открою страшную тайну: Свой CPU, свою OS и стандартную библиотеку своего языка Вы используете на 20%. Есть-ли смысл?
3. Документация? Вы сейчас точно про Джангу?
Там есть и гайд (который проходится за 3 часа и знакомит Вас с 80% возможностей джанги) и отличный референс
https://docs.djangoproject.com/en/1.7/contents/
У лифта же нет документации кроме видео (!) про геттинг стартед и кукбука (!!).
Мне кажется что дискуссию можно сворачивать) Выбор фреймворка это вопрос вкуса, и мне кажется что у Вас просто был bad experience в Джангой и потому Вы ее не любите (как вариант -- Скала нравится вам больше Пайтона, это логично)). В главном мы сошлись: какой-то фреймворк все-таки нужен. Не нужно руками писать SQL запросы, выводить HTML через писание в поток, и в конце концов не нужно делать вот так: http://govnokod.ru/17083
А код без фреймворка практически всегда именно так и выглядет
guest 09.11.2014 04:23 # 0
>шаблоны, ОРМ и еще кучу всего, что мне не понадобится в хобби-проекте
то проще взять изкоробочный htppserver или сразу пхп?
Хотя джанга для начала действительно сложновата.
Анонимус 09.11.2014 14:06 # +1
guest 10.11.2014 08:23 # 0
doo_dee_doo_dmt 08.11.2014 00:01 # 0
лично я, если для товарища - взял бы говнобитрикс или оскомерс... уж точно не джангу, чтоб он меня потом проклинал ища питонистов... ну хоть не лисперов...
Насчет задачи. Кроме как вывести это все, потом ведь заказчик захочет корзину, фильтры и поиск... и придем к тому, о чем говорил wvxvw...
Саму задачу и на вермешелекоде с копипастами можно за день наколбасить - вопрос поддержки. Собственно, что и с джангой.
Анонимус 08.11.2014 00:09 # 0
2) Любой CMS в известной степени ограничивает. Есть определенный шанс на то, что НЕ ЛЮБУЮ верстку можно натянуть на битрикс.
3) Давайте вопросы рынка вынесем за пределы: считайте что поддерживать его будете Вы. Тот факт что пыховой школоты (кстати, не факт что школота умеет битрикс) куда больше чем питонячей к вопросу наличия фреймворка отношения не имеет.
4) Конечно он потом захочет корзину, форум, и черта лысого в ступе.
5) На вермешель коде можно заколбасить за день, и потом получить XSS, SQL Injection, неподдерживаемый код и потраченный день. На джанге можно сделать поддерживаемо, безопасно и за несколько часов.
Речь тут не о джанге как таковой, а о выборе фреймворка в целом.
Товарищ сказал что они не нужны. В итоге мы договорились до того, что он взял бы Lift. Тоесть он признал таки необходимость наличия фреймворка.
Вы тоже предложили фреймворк, правда вместе с CMS, тоесть все ж таки косвенно подтвердили мои слова:)
doo_dee_doo_dmt 08.11.2014 00:20 # 0
Битрикс - относительно платен. Доступен любому мелкому ИП, всяко меньше, чем прогерам платить. Шаблон можно любой натянуть. Там фактически таже вермишель в шаблонах, только доступ к базе через обертку.
Вы выступили с задачей без контекста.
Можно решить втупую, а можно задуматься о дальнейшем развитии. Вот тут и начинаем подбирать не фреймворк, а инструмент вцелом.
Вопрос как проект будет развиваться - от этого будет зависеть и выбор. Если вы знаете джангу, и подписались поддерживать проект - то должны взять именно ее, об чем может быть вообще тут спор?
Анонимус 08.11.2014 00:48 # 0
Дело тут не в Джанге: с таким же успехом можно говорить о рейлс, или грейлс, или плее или cakephp итд. Важно что есть некий фреймворк который решает типовые задачи из которых такой сайт состоит чуть менее, чем полностью:)
Конечно же в серьезном проекте надо писать много своего кода. Но это не повод вручную реализовывать защиту от XSS или формочку для загрузки картинки:)
doo_dee_doo_dmt 08.11.2014 01:30 # 0
Так категорично говорить нельзя. В целом у нас вообще только один критерий: don't repeat yourself. Следуя ему товарищ либо в итоге возмет подходящий фреймворк либо напишет свой... Накладные расходы? Зависит от задачи.
Анонимус 06.11.2014 19:54 # 0
Они тоже не понимали зачем писать на си, а потом переписывать вручую боттлнеки (компиляторы тогда были тупые).
А потом они поняли что переписать надо только 20%. Закон Парето тоже.
Тоже самое с ORM.
Типовой проект с вебмордой на 80% состоит из тупых формочек и круда которые отлично покрываются типовым фреймворком.
Горячие места можно переписать вручную. Достаточно гибкие ОРМы это позволяют.
wvxvw 06.11.2014 20:21 # 0
Распихано? - сужу по опыту Хай-бернейта. Классы с его аннотациями как правило встречаются равномерно во всем приложении. В Джанго как бы тоже может быть много контроллеров, распиханых где угодно. Когда я смотрю в наш проект на Джанго, я как бы даже вообще не представляю почему кому-то когда-то в голову пришла мысль поместить этот класс модели в это конкретное место. И почему он так а не по-другому работает с базой данных.
Наши еще вообще молодцы. Они решили поиск написать с использованием ОРМ. Т.е. поиск не просто подстроки, а с синонимами, контекстом и исправлением ошибок. Т.е. как бы назначение базы данных в первую очередь обеспечить хранение и быстрый доступ, но когда ее исползуют именно для этого через ОРМ оказывается что ОРМ не решает никаких проблем, но создает кучу. В итоге потому что наши питонисты нихера не понимают в Сиквеле, поиск таки работает с ОРМ. Херня полнейшая, дикие тормоза и результаты не выдерживают никакой критики.
Архитектуры всегда ужасные. Это нужно принимать за базовую оценку. При оценке чего-то нужно исходить из того, что архитектура будет херовой. Что программисты будут нубами, леняями и т.д. Иначе, если оптимизировать условия, а не решения, можно просто захерачить в код одну универсальную константу, и сказать, что идеал достигнут.
bormand 06.11.2014 20:29 # 0
Анонимус 06.11.2014 20:34 # +1
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 запросы встречаются у вас во вью, в шаблонах, и вообще везде, то это конечно ужасный рак, и вот от такого действительно страдают многие приложения.
Анонимус 06.11.2014 19:51 # 0
>>коллекции равнозначны и мапятся в один и тот же класс
Не всегда. В крупных системах можно встретить наследование)
>> Грубо говоря, мы получаем объект ПОТОКА данных и его пихаем в представление, целиком.
Если все поля документа равнозначны то да, мы ничего не нарушаем.
Если же мы хардкодим в шаблоне знание о том что по ключу foo лежит int, а по ключу bar -- float, то это уже не так хорошо.
doo_dee_doo_dmt 06.11.2014 23:27 # 0
<ul>
{% for item in items %}
<li><a href="{{ item.href }}">{{ item.title }}</a></li>
{% endfor %}
</ul>
Вот какая разница - item это объект или ассоциативный массив?
Анонимус 06.11.2014 23:33 # 0
Просто иногда шаблон хочет форматировать даты, например.
И тогда ему важно знать что в поле birthday лежит дата.
Другой вариант это Ящик Пандоры в шаблонах:
Хотя конечно в идеальном мире всё это должно хендлится уровнем выше (во вьюшках в терминах джанги например) и в шаблонизатор может смело приезжать string-string.
Но опять же: где-то же должны эти преобразования происходить. Если не в модели, то во вьюхе. Ну а худые модели и толстые вьюхи/контроллеры все равно приведут к копи-пасте
doo_dee_doo_dmt 07.11.2014 00:10 # 0
Вьюха тут должна хардкодить однозначно. Вьюху вы передаете верстальщику - это его дело, как дату представлять.
doo_dee_doo_dmt 07.11.2014 00:19 # 0
ну короче в шаблон передаем чистую дату, не стринг, я это имел ввиду.
А уровнем выше вьюху стараемся как можно меньше трогать вообще, лучше никогда.
doo_dee_doo_dmt 07.11.2014 01:56 # 0
То есть мы должны выводить поля автоматически. Когда мы в шаблоне точно знаем че как - это один кейс, а когда автоматически - все немного по-другому... но и в этом случае как таковой орм не является необходимым.
Думаю вот как-то так выводим автоматическую форму (примитивно, конечно):
где input - это колбэк (живет скорее всего во вьюхе, как у вас в терминах пытхона, ну или в контроллере), он по переданным параметра генерит хтмл с нужным инпутом (пихает параметры в нужный шаблон для инпута и отдает отрендеренный результат).
properties - могут быть сгенерированы впринципе автоматом из модели (по дефолту) и пофичены во вьюхе или контроллере, а могут и в базе лежать, как метданные. В любом случае и для метаданных орм не является необходимым.
И еще заметьте одну штуку. Типы полей в базе - это не одно и тоже, что типы полей на форме, они не всегда мапятся один-в-один.
Efog 10.11.2014 08:54 # 0
roman-kashitsyn 10.11.2014 09:26 # +2
bormand 10.11.2014 09:34 # 0
inkanus-gray 10.11.2014 14:37 # 0
bormand 10.11.2014 15:42 # 0
huesto 15.01.2017 02:06 # 0
barop 15.01.2017 02:21 # 0
huesto 15.01.2017 02:33 # 0
barop 15.01.2017 02:52 # −1
bormand 15.01.2017 06:37 # 0
dxd 15.01.2017 17:34 # 0
bormand 15.01.2017 17:40 # 0
barop 15.01.2017 01:36 # 0
guest 10.03.2017 15:21 # 0
guest 14.01.2017 20:52 # 0
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
guest 14.01.2017 21:01 # +1
guest 10.03.2017 08:44 # 0
На страницах Интернет-магазина вы сможете найти парсеры и грабберы для Интернет-торговли, приобрести информацию с базами контактов и 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>. Вложенные данным образом средства помогут повысить вашу прибыль на порядок!