1. PHP / Говнокод #17058

    +156

    1. 01
    2. 02
    3. 03
    4. 04
    5. 05
    6. 06
    7. 07
    8. 08
    9. 09
    10. 10
    11. 11
    12. 12
    13. 13
    14. 14
    15. 15
    16. 16
    17. 17
    18. 18
    19. 19
    20. 20
    21. 21
    22. 22
    23. 23
    24. 24
    25. 25
    26. 26
    27. 27
    28. 28
    29. 29
    30. 30
    31. 31
    32. 32
    33. 33
    34. 34
    35. 35
    36. 36
    37. 37
    38. 38
    39. 39
    40. 40
    41. 41
    42. 42
    43. 43
    44. 44
    45. 45
    46. 46
    47. 47
    48. 48
    49. 49
    50. 50
    51. 51
    52. 52
    53. 53
    54. 54
    55. 55
    56. 56
    57. 57
    58. 58
    59. 59
    60. 60
    61. 61
    62. 62
    63. 63
    64. 64
    65. 65
    66. 66
    67. 67
    68. 68
    69. 69
    70. 70
    71. 71
    72. 72
    73. 73
    74. 74
    75. 75
    76. 76
    77. 77
    78. 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;
            }
        }
    ?>

    Мой шаблонизатор. Детям и беременным женщинам не смотреть.

    Запостил: Efog, 03 Ноября 2014

    Комментарии (113) RSS

    • зачем всё это?
      Ответить
      • Шаблонизатор ведь.
        Ответить
        • Зачем еще один шаблонизатор?
          Их мало?
          Ответить
          • Своё всегда приятнее ведь.
            Ответить
            • Это да.

              Нужно всегда написать свои ООП обертки для коллекций, свой шаблонизатор, свой CMS , свой форум и свою социальную сеть.
              Ответить
              • Угадал, сейчас я пишу свой CMS. Ибо посмотрев код DLE, мои глаза вылезли и не хотят идти обратно.
                Ответить
                • Я надеюсь у Вас там будет свой собственный ORM?
                  Ответить
                  • Пока не намечается. Если я узнаю, чем использование ORM удобнее обычных SQL-запросов, обязательно сделаю.
                    Ответить
                    • аа) так у Вас всё еще впереди)
                      удачи!
                      Ответить
                    • нет ничего удобнее обычных SQL-запросов, пока не потребуется применить группировку™
                      Ответить
                      • А вот это да, сам с этим столкнулся.
                        Ответить
                        • это был сарказм
                          на деле же даже jpa и прочий хайбернейт посасывают в заметной части случаев у обычных нативных запросов
                          Ответить
                          • Сарказм или нет -- но у меня всё именно так :D
                            Вот, в моих ГК есть запрос с группировкой, пол часа с ним еб*лся, хотя вроде и можно как-то проще сделать.
                            Ответить
                            • это в том, где надо было выбрать последние посты для каждого топика?
                              даже для mysql есть несколько способов в рамках общих правил sql
                              и даже без единого group by
                              Ответить
                              • к примеру
                                select u.*, c.*, t.*
                                from users u  -- джойним юзеров, топики и каменты как обычно
                                   join comments c
                                     on (c.user_id = u.id)
                                   join topics t
                                     on (t.id = c.topic_id)
                                   left outer join comments c2  -- как бы ищем коммент из того же топика, который был бы позднее коммента c
                                     on (c.topic_id = c2.topic_id and c2.created_time > c.created_time)
                                where c2.id is null  -- и выбираем те строки, где нет таких c2, которые были бы больше значения в c
                                order by c.created_time desc -- сортируем по убыванию
                                дальше можно забирать первые 10 или сколько там надо было
                                Ответить
                                • И молимся, чтобы в мускуле этот запрос не поимел квадратичную сложность от количества комментов в треде... Вариации с where not exist это тоже касается.
                                  Ответить
                                  • ну, скорее всего, так и получится
                                    не только в мускуле собсно
                                    http://sqlfiddle.com/#!4/769c4/1
                                    это просто был пример решения без групп бабайки
                                    Ответить
                      • нет ничего удобнее обычных SQL-запросов, пока не потребуется сделать динамический фильтр
                        Ответить
                        • нет ничего удобнее обычных SQL-запросов, пока не окажется что в системе есть 14 таблиц и для каждой нужно сделать CRUD
                          Ответить
                          • круд нифига не критерий для орм. Можно и на уровне всей коллекции делать общие операции, не преобразовывая документ в объект.

                            орм нужен для инкапсуляции поведения. Из базы вычитываем параметры объекта и вызываем методы, которые у себя внутри используют эти параметры. Получается универсальность. Сохранение объектом самого себя (по айди например) - как одно из инкапсулированных действий.
                            Ответить
                            • Даже если "не преобразовывая документ в объект" (хотя тогда непонятно как отображать вычисляемые в коде поля) то все равно без ОРМ будет куча бойлерплейта.

                              Остальную часть не очень понял, но инкапсуляция это безусловно один из плюсов ОРМ.

                              Итого плюсы орм:
                              1) собственно OR/M: маппинг кучи полей объекта в поля таблицы (и наоборот)
                              2) динамическое построение запросов в терминах объекта а не базы
                              3) кеш
                              4) в легких случаях относительная бд независимость
                              5) ну всякие плюшки вроде физической невозможности SQL injection и прочей херни
                              6) легкий CRUD аут оф бокс
                              Ответить
                              • вы просто смешиваете понятия. 5 - как к таковому орм не относится. 4 - бд независимость можно сделать без преобразования в объект, если сделать обертку на уровне всей коллекции.
                                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 абсолютно всегда делать объект, но это весьма спорный аргумент.
                                        Ответить
                                        • Хз. На мой взгляд, принципиально, ОРМ безнадежное занятие изза того, что уникальность объектов и уникальность таблиц это несовместимые вещи. И эта несовместимость рано или поздно даст о себе знать каким-нибудь нехорошим способом. Собственно, больше всего борьбы в ОРМ происходит именно по этой причине: синглтоны, рейсы, апдейты со сложноподвыподвернутыми графиками и взаимоотношениями.

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

                                          Если посмотреть на базу данных с которой работало приложение с ОРМ, она больше всего напоминает минифицированый ж.скрипт. Т.е. оно вроде и рабочее, но пользоваться им без приложения уже нельзя.
                                          Ответить
                                          • Без меры орм - это ад. А вот если нужна реальная инкапсуляция поведения объекта - то очень хорошая штука. Типо

                                            $user = $this->db->user->find(['login'=>$login])
                                            
                                            if (!$user->auth(['password' => $password])) {
                                                throw new HttpStatus(401);
                                            }
                                            
                                            $user->sendMessage('Превед');


                                            Без орм будет не красиво.
                                            Ответить
                                            • У Вас тоже не очень красиво.
                                              Красиво было бы так:

                                              $this->db->user->find($login)
                                              $user->auth($password)
                                              Ответить
                                              • )) неа. Поиск может быть еще по другим полям, аутентификация может быть не только по паролю
                                                Ответить
                                                • Литерал 'login' тут это имя поля в базе?)
                                                  Ответить
                                                  • > имя поля в базе
                                                    Вот такая вот она, пыховская инкапсуляция.
                                                    Ответить
                                                    • Ну есть еще надежда что я не прав, и что просто у этого метода такой странноватый контракт, и что знание об имени поля в базе не прорвалось на один уровень со знанием про HttpStatus.

                                                      Иначе это тот самый кейс, про который я писал ниже: люди сначала завязывают всю систему на знание о БД, а потом не могут поменять конкретный вызов на SQL запрос (потому что пол системы надо перепахать) и делают вывод что ОРМ гумно
                                                      Ответить
                                                      • А толку если я напишу findByLogin($login)?

                                                        Звать все равно надо, так проще типа фильтра сделать.

                                                        По большом счету поле не совсем в базе, а через обертку.

                                                        Если уж там вам надо поле переименовать. Контракт останется контрактом, кто мешает переименовывать на уровне модели-то?
                                                        Ответить
                                                        • >>А толку если я напишу findByLogin($login)?

                                                          Будет много лучше.

                                                          Знаете, контракт:

                                                          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'ы и, если понадобится, допилить мелочи напильником :(
                                              Ответить
                                              • у пайтонистов принято хвалить SQLалчеми и ругать родной джанговый ORM.

                                                Мне кажется что когда-нибудь алчеми с джангой поженятся.
                                                Ответить
                                                • > ругать родной джанговый ORM
                                                  Я не ругаю родной джанговый ORM, ибо не юзал его ;)

                                                  Юзать джангу ради простенького REST сервачка, имхо, как забивать гвозди микроскопом.
                                                  Ответить
                                                  • Ну если Вы достаточно хорошо знаете джангу то простенький REST сервачок делается на ней за 5 минут, и почему бы не поюзать.

                                                    Вот изучать джангу ради такого это имхо перебор
                                                    Ответить
                                                    • > Вот изучать джангу ради такого это имхо перебор
                                                      this
                                                      Ответить
                                                      • Наши на Джанго посторили приложение, в котором есть ну... страниц десять уникальных + админка (какой-то модуль Джанго же). Админка - то еще месиво, но не про нее сейчас. Вобщем, система планировалась людьми, которые очень любят фреймворки и видят в них спасение от собственной отсуствующей / слабой компетентности. Но, как выяснилось, не спасает.

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

                                                        Вобщем, я пробовал и на Джанго простенький сервер (для тестов) и с Торнадо и с Твистед и просто BaseHTTPServer. В итоге, 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 отдать то да -- джанга Вам не нужна;)
                                                          Ответить
                                                          • Джанго появился примерно одновременно с Зендом, ASP.NET MVC (на год раньше / одновременно) и на три года позже Спринга и рельсов. Вот про эту моду я говорил.

                                                            Про BaseHTTPServer был комментарий bormand'у о личном опыте написания разовых веб-серверов без особых требований и желательно побыстрее. Где я неявно продвигаю мысль о том, что фреймворки, которые так долго говорили о том, как они сделают все проще для их пользователей, на самом деле не сделали все проще для пользователей.

                                                            ХЗ. Я не вижу какой-то хорошей области применения Джанго. Затраченые усилия не соответствуют результату. Он не освобождает от кропотливой и мучительно долгой работы над большими проектами и не очень-то уменьшает количество этой работы для маленьких проектов (особенно за счет настроек самого Джанго). Вот, Флекс тоже относится примерно к этой же эпохе, и во многих отношениях точно так же себя проявил. Маленькие приложения на нем делать бессмысленно т.как не хочется за собой тянуть почти четыре мегабайта фреймворка, ничего почти не сэкономив по времени на производство, а когда приложение вырастает до чего-то большего, оказывается что с фреймворком очень много проблем, и их решение занимает все свободное и внеурочное время.
                                                            Ответить
                                                            • 1. Ну Вы понимаете же что сравнивать BaseHTTPServer и Django совершенно бессмысленно, правда?

                                                              2. Флекс это фреймоврк для создания гуи поверх флеша, и впринципе он был довольно хорош, но был убит HTML5, и поделом. Честно говоря я не понимаю как без флекса на флеше можно было делать GUI и что плохого в четырех мегабайтах.

                                                              3. Ну вот вам пример задачи под джанго. Есть список из ста товаров, товары могут относиться к одной или более категорий, нужно дать продавцу возможность быстро заполнять базу товарами, а покупатели могут их просматривать по категориям.
                                                              У Вас есть дизайн и верстка. На Джанго это делается примерно за пару часов. А что будете делать Вы?
                                                              Ответить
                                                              • > был убит HTML5
                                                                Ну-ну. Живее всех живых в некоторых областях. Те же флеш-телефоны или видеостримы. Там вариантов просто нет. Емнип, они все с флексом.
                                                                Ответить
                                                                • Ну из мира "рич аппликейшенс" его вымывает HTML5, во всяком случае.
                                                                  Бедняга ютится в Adobe Air)

                                                                  Кстати, у меня были коллеги которые довольно много писали на экшен скрипте под флекс. Они говорили что там хуёво всё начиная от документации, и кончая IDE на эклипсе.
                                                                  ---
                                                                  Жаба аплеты тоже царствовали в вебе 1.0 (в то время на них даже кнопочки делали, прямо на свинге!)
                                                                  А потом MS по требованию SUN выкинул JRE из стандартной поставки IE и аплеты сдулись.
                                                                  Ответить
                                                                  • > довольно много писали на экшен скрипте под флекс
                                                                    Ну я только доводил до ума телефончик на флексе. IDE не юзал, правил обычным редактором, компилил скриптом из консольки.

                                                                    Но подтверждаю. Хуёвость начинается с загрузки SDK под линь. Это был целый квест... Документация не айс, да. Но если сравнивать с "продуктами" типа джумлы - она хотя бы есть. И разобраться до уровня "доработать напильником, добавить своего говнеца с externalInterface и натянуть нарисованный коллегой дизайн" - оказалось вполне реально за пару дней. Но больше связываться с миром флеша\флекса что-то не хочется.
                                                                    Ответить
                                                                    • Ну всё таки флекс пилили адоб, а это ребята по-серьезнее чем пых-школота из джумлы, было бы странно если бы флекс был хуже даже джумлы!
                                                                      Ответить
                                                                  • P.S. А вот из плюсов флекса - там можно задавать стили для сабконтролов. Например для выпадающих пунктов в комбиках и т.п. В хвалёном хтмл5 до этого почему-то не додумались.
                                                                    Ответить
                                                                    • Я помню что там был какой-то свой особый CSS и язык MXML)

                                                                      Вообще задавать можно, но работает как-то частично и не везде:
                                                                      <style type="text/css">
                                                                        .eggs {
                                                                          font-family: "Courier New", Courier, monospace;
                                                                          font-weight: bold;
                                                                          color: red;
                                                                          background-color: #008000;
                                                                        }
                                                                      </style>
                                                                      <select multiple="multiple">
                                                                        <option>foo</option>
                                                                        <option>bar</option>
                                                                        <option class="eggs">eggs</option> <!-- будет цветной -->
                                                                        <option>spam</option>
                                                                      </select>
                                                                      Ответить
                                                              • Их никто и не сравнивает... я говорю о том, что... но я уже только что об этом говорил :S

                                                                Нет, Флекс это не фреймворк для создания ГУЯ поверх Флеша. Во Флексе есть дофига всего и компилятор свой и какие-никакие инструменты для работы с SWF форматом, шаблонизатор (на базе Velocity), кодировщики, и работа с коллекциями и RPC и система оповещения о изменениях свойств объектов, и какие-то зачатки криптографии, и парсеры каких-то популярных форматов файлов, и это все идет в нагрузку к ГУЮ. Пример ГУИ фреймворка для Флеша - Старлинг.

                                                                Флекс всегда был говном, с самого его рождения и по сей день, но зато бесплатным. За что ему можно многое простить. Практически все, кто им пользовался жили с надеждой что не ровен час Адоби его существенно улучшат и перепишут с нуля.

                                                                ХТМЛ тут как бы не приделах, он находится с Флексом в ортогональной плоскости.

                                                                Последний вопрос: у вас есть ракетное топливо и один скафандр. На Байконуре это делается за секунды, а что будете делать вы?
                                                                Ответить
                                                                • Флекс создавался чтобы занять нишу Rich Media Applications (был такой баззворд в конце нулевых), и там конкурировал с JavaFX (умер не родившись) и Silver Light (умирает), и HTML5 (кажется, живет). Возможно, у флекса есть и другие применения, но мы не о них.

                                                                  Ну а о говёности я уже писал выше: все говорят что флекс говно, вот и Вы тоже так говорите)

                                                                  Про Байконур: аналогия не совсем ясна. Байконур строить долго и дорого, а Джанго изучается за неделю. Устанавливается коммандой "pip install django". Поддерживается IDE (PyCharm, например). После этого у Вас есть инструмент для быстрого решения приведенной мною задачи.
                                                                  Ответить
                                                                  • И вообще, если уж на то пошло, то Флекс это веб-сервер (в изначальной задумке, которая до сих пор присутствует в коде). Этот сервер должен был на лету генерировать SWF файлы из MXML "страниц". Конечно, еще на заре этого проекта стало понятно, что с такой раздутой базой кода в реальном времени собирать странички не получится. Но веб-часть так и не убрали.
                                                                    Ответить
                                                                    • >> Флекс это веб-сервер

                                                                      Мне, все же, больше нравится определение педивикии:
                                                                      [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 человек в день.

                                                                          Мне кажется информации достаточно для примерного выбора технологии, разве нет?
                                                                          Ответить
                                                                          • 10 человек в день - я бы не брался, ну или только если друг попросил, или что-то такое. Если делать это просто как хобби - то, как мне кажется, без разницы какой там фреймворк и т.д. лишь бы работать было приятно.
                                                                            Ответить
                                                                            • Ну хорошо, 1000 человек в день. Важно что их не сто тысяч одновременно, так что о хайлоде думать не нужно. Ну и конечно же друг попросил. У друга ИП, ему нужен такой вот сайт.

                                                                              Так как бы Вы делали такой проект?) Использовали бы Django/Рельсы/WhatEver, или писали бы всё с ноля, включая формочку для загрузки картинок?
                                                                              Использовали-бы Django ORM, или вручную написали бы SQL запросы для создания, поиска и удаления товаров и категорий?)
                                                                              Ответить
                                                                              • Если друг попросил? Ну, зависит от того, что у друга есть в наличие. Но друг он обычно такой, что простит если работа будет делаться по вечерам пару часов в день. Я бы наверное смотрел в сторону Кложуры / Скалы, просто ради поэксперементировать. Для похожих минималистичных задач (несколько человек собрались порешать программерские / математические головоломки), я делал на Эльноде и на Ханчентуте. Но это потому что участникам было бы проще разобраться с сервером.
                                                                                Делал один раз на Хексе, просто попробовать. Хз. не особо чет меня как-то порадовал он. Еще пробовал, например, попользоваться Нио в связке с Твистед. Плохая связка. Нио ни с чем хорошо кроме Явы не работает.
                                                                                Ну и та же НодаЖС - как вариант, если на сервере совсем ничего делать не надо.
                                                                                Ответить
                                                                                • Давайте все-таки решим что Вам нужно сделать такой вот минипроект, а не поэксперементировать с языками, иначе мы сейчас будем писать это на ELM (elm-lang.org) (потому что интересно), а там очевидно фреймворков готовых нет.

                                                                                  Допустим Вы выбрали скалу под JVM.
                                                                                  Дальше-то что будет?

                                                                                  Вы будете напрямую реализовывать интерфейс
                                                                                  javax.servlet.http.HttpServlet
                                                                                  ?
                                                                                  Ответить
                                                                                  • Нет, такое в голову не приходило. Ну тут сравнение неправильное если имеется в виду BaseHTTPServer. BaseHTTPServer это как JBoss а не как Servlet. Т.е. это готовый продукт, а не конструктор.

                                                                                    Если это Скала, то наверно Лифт буду смотреть. Я не так чтобы сильно знаком. Наверное тупо скачал бы какой-нибудь маленький проект с Гитхаба и начал бы его перепиливать под то, что мне нужно.
                                                                                    Ответить
                                                                                    • Я не про BaseHTTPServer говорил) Просто люди в мире JVM частенько любят использовать контейнеры сервлетов (JBoss, Tomcat, Jetty итд) чтоб не диспатчить HTTP вручную. Но конечно можно и без них.

                                                                                      Главное тут что Вы бы все таки взяли бы какой-нибудь фреймворк. Lift, например. Тоесть Вы не стали бы вручную реализовывать MVC, шаблонизатор итд.
                                                                                      Вы взяли бы фреймворк который это делает не смотря на массу кода, который он генерит) и даже не смотря на то, что Лифт имеет ОРМ:

                                                                                      http://demo.liftweb.net/database

                                                                                      Барабанная дробь: Джанго делает тоже самое!

                                                                                      Почему же Джанго не нужно, а Лифт нужен?
                                                                                      Ответить
                                                                                      • Так я не против использования чужих библиотек. Я против использования библиотек, где за очень большую плату дают очень мало. Джанго - это пример, когда кривая описывающая соотношение требований к затратм никогда не пересекается с кривой предложений-затрат. Т.е. нет таких проектов, которые бы имело смысл делать с использованием Джанго. Либо они слишком простые (и если их делать с использованием Джанго - неоправдано раздутые), либо Джанго не спасает от сложности. Сложности практически всегда уникальные и на каждую из них найти ответ очень сложно, и поэтому фреймворк вынужден ограничиваться какими-то общими решениями, которые в итоге являются не-решениями.

                                                                                        Если бы, например, выбросить из Джанго шаблоны, ОРМ и еще кучу всего, что мне не понадобится в хобби-проекте, то мне проще будет взять Торнадо вместо - меньше настроек, быстрее работает, меньше требований к пользовательскому коду.

                                                                                        Если мне нужно делать что-то более сложное, то это будет опять же уникальный проект, который, скорее всего будет пользоваться разными библиотеками для разных вещей, но они не будет библиотеками Джанго, потому что практически для всего, что может сделать Джанго есть лучшие альтернативы.
                                                                                        Ответить
                                                                                        • Можно узнать какую плату требует от Вас Джанго?
                                                                                          Не нравятся шаблоны -- не используйте. Не нравится ORM -- не используйте. Я правда не понимаю что в этом такого.

                                                                                          Тот факт что Вы опять упоминаете Торнадо который нужен для работы по HTTP а не для построения веб приложений говорит о том, что мы вернулись к тому, с чего начали. Торнадо Вам никак не поможет ни с шаблонизацией ни с БД ни с КРУД ни с чем. Это просто HTTP.

                                                                                          Ну и самое главное: в Вашем тексте Вы можете заменить слово "Django" на слово "Lift", и попытаться прочитать его снова;)
                                                                                          Ответить
                                                                                          • Нет, не могу заменить Джанго на Лифт. Это как раз и есть основная идея того, что я написал выше. Лифт - просто веб фреймворк, он не пытается заниматься вещами помимо его непосредственного назначения.
                                                                                            С Джанго, наоборот, получается ситуация, что если подписался на что-то одно, то вынужден использовать и остальное. Ну какой смысл делать сайт на Джанго а админку к нему не на Джанго? Это ж все равно что на зло водителю купить билет и пойти пешком.

                                                                                            ПС. Кроме того, у Джанго очень херовая документация. Не в смысле что ее мало, а в том слысле, что она очень безалаберно организована (т.е. вообще не организована никак). Просто найти класс или функцию которая должна делать что-то, что предположительно Джанго умеет делать - можно день потратить.
                                                                                            Ответить
                                                                                            • 1. Совершенно нет никакой разницы между Джангой, Рельсами и Лифтом. И то и другое и третье --- просто фреймворки примерно одного уровня.

                                                                                              2. Смысл в том что Вы получаете бесплатно кучу всего, и можете использовать что Вам нужно. Открою страшную тайну: Свой CPU, свою OS и стандартную библиотеку своего языка Вы используете на 20%. Есть-ли смысл?

                                                                                              3. Документация? Вы сейчас точно про Джангу?

                                                                                              Там есть и гайд (который проходится за 3 часа и знакомит Вас с 80% возможностей джанги) и отличный референс
                                                                                              https://docs.djangoproject.com/en/1.7/contents/

                                                                                              У лифта же нет документации кроме видео (!) про геттинг стартед и кукбука (!!).

                                                                                              Мне кажется что дискуссию можно сворачивать) Выбор фреймворка это вопрос вкуса, и мне кажется что у Вас просто был bad experience в Джангой и потому Вы ее не любите (как вариант -- Скала нравится вам больше Пайтона, это логично)). В главном мы сошлись: какой-то фреймворк все-таки нужен. Не нужно руками писать SQL запросы, выводить HTML через писание в поток, и в конце концов не нужно делать вот так: http://govnokod.ru/17083

                                                                                              А код без фреймворка практически всегда именно так и выглядет
                                                                                              Ответить
                                                                                        • >Если бы, например, выбросить из Джанго шаблоны, ОРМ и еще кучу всего, что мне не понадобится в хобби-проекте
                                                                                          >шаблоны, ОРМ и еще кучу всего, что мне не понадобится в хобби-проекте
                                                                                          то проще взять изкоробочный htppserver или сразу пхп?

                                                                                          Хотя джанга для начала действительно сложновата.
                                                                                          Ответить
                                                                                          • Всё что угодно сначала сложновато) Но Джанго -- не теория струн. Она изучается за неделю)
                                                                                            Ответить
                                                                                            • web.py - за полдня. Жалко, что на тройке его нет. Кстати, что лучше использовать для json api?
                                                                                              Ответить
                                                                              • Можно вмешаюсь?

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

                                                                                Насчет задачи. Кроме как вывести это все, потом ведь заказчик захочет корзину, фильтры и поиск... и придем к тому, о чем говорил wvxvw...

                                                                                Саму задачу и на вермешелекоде с копипастами можно за день наколбасить - вопрос поддержки. Собственно, что и с джангой.
                                                                                Ответить
                                                                                • 1) разве битрикс бесплатен?
                                                                                  2) Любой CMS в известной степени ограничивает. Есть определенный шанс на то, что НЕ ЛЮБУЮ верстку можно натянуть на битрикс.
                                                                                  3) Давайте вопросы рынка вынесем за пределы: считайте что поддерживать его будете Вы. Тот факт что пыховой школоты (кстати, не факт что школота умеет битрикс) куда больше чем питонячей к вопросу наличия фреймворка отношения не имеет.
                                                                                  4) Конечно он потом захочет корзину, форум, и черта лысого в ступе.
                                                                                  5) На вермешель коде можно заколбасить за день, и потом получить XSS, SQL Injection, неподдерживаемый код и потраченный день. На джанге можно сделать поддерживаемо, безопасно и за несколько часов.

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

                                                                                  Вы тоже предложили фреймворк, правда вместе с CMS, тоесть все ж таки косвенно подтвердили мои слова:)
                                                                                  Ответить
                                                                                  • Я думал речь идет про выбор инструмента под задачу.

                                                                                    Битрикс - относительно платен. Доступен любому мелкому ИП, всяко меньше, чем прогерам платить. Шаблон можно любой натянуть. Там фактически таже вермишель в шаблонах, только доступ к базе через обертку.

                                                                                    Вы выступили с задачей без контекста.

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

                                                                                    Вопрос как проект будет развиваться - от этого будет зависеть и выбор. Если вы знаете джангу, и подписались поддерживать проект - то должны взять именно ее, об чем может быть вообще тут спор?
                                                                                    Ответить
                                                                                    • Беседа началась с того что товарищ заявил, дескать Джанга не нужна. И вообще фреймворки не очень нужны: они только маскируют неумение программистов писать код) И задач для Джанги нет. Вот я и привел пример такой задачи)

                                                                                      Дело тут не в Джанге: с таким же успехом можно говорить о рейлс, или грейлс, или плее или cakephp итд. Важно что есть некий фреймворк который решает типовые задачи из которых такой сайт состоит чуть менее, чем полностью:)

                                                                                      Конечно же в серьезном проекте надо писать много своего кода. Но это не повод вручную реализовывать защиту от XSS или формочку для загрузки картинки:)
                                                                                      Ответить
                                                                                      • Вопрос не такой уж однозначный. Всегда ли нужна защита от хсс? Нет, если это сайт визитка, какая-нибудь или вообще статичная страница с яваскриптом без обращения к серваку. Так ли сложно сделать форму загрузки картинки и вообще подойдет ли универсальная, если на фронтенде прикручен bootstrap, например?

                                                                                        Так категорично говорить нельзя. В целом у нас вообще только один критерий: don't repeat yourself. Следуя ему товарищ либо в итоге возмет подходящий фреймворк либо напишет свой... Накладные расходы? Зависит от задачи.
                                                                                        Ответить
                                          • Ваши рассуждения напоминают рассуждения программистов 70х которых пересаживали с асма на си.
                                            Они тоже не понимали зачем писать на си, а потом переписывать вручую боттлнеки (компиляторы тогда были тупые).
                                            А потом они поняли что переписать надо только 20%. Закон Парето тоже.

                                            Тоже самое с ORM.

                                            Типовой проект с вебмордой на 80% состоит из тупых формочек и круда которые отлично покрываются типовым фреймворком.

                                            Горячие места можно переписать вручную. Достаточно гибкие ОРМы это позволяют.
                                            Ответить
                                            • Нет, ситуация не похожа на Ассемблер / Си. Сиквел - язык более выского уровня, чем та же Ява или Питон. Переделывать с Сиквела в Яву - это как раз переделывать с Си в Ассемблер.

                                              Распихано? - сужу по опыту Хай-бернейта. Классы с его аннотациями как правило встречаются равномерно во всем приложении. В Джанго как бы тоже может быть много контроллеров, распиханых где угодно. Когда я смотрю в наш проект на Джанго, я как бы даже вообще не представляю почему кому-то когда-то в голову пришла мысль поместить этот класс модели в это конкретное место. И почему он так а не по-другому работает с базой данных.

                                              Наши еще вообще молодцы. Они решили поиск написать с использованием ОРМ. Т.е. поиск не просто подстроки, а с синонимами, контекстом и исправлением ошибок. Т.е. как бы назначение базы данных в первую очередь обеспечить хранение и быстрый доступ, но когда ее исползуют именно для этого через ОРМ оказывается что ОРМ не решает никаких проблем, но создает кучу. В итоге потому что наши питонисты нихера не понимают в Сиквеле, поиск таки работает с ОРМ. Херня полнейшая, дикие тормоза и результаты не выдерживают никакой критики.

                                              Архитектуры всегда ужасные. Это нужно принимать за базовую оценку. При оценке чего-то нужно исходить из того, что архитектура будет херовой. Что программисты будут нубами, леняями и т.д. Иначе, если оптимизировать условия, а не решения, можно просто захерачить в код одну универсальную константу, и сказать, что идеал достигнут.
                                              Ответить
                                              • > идеал достигнут
                                                void сделатьЗаебись() {
                                                   throw new RuntimeException("Не дождешься!");
                                                }
                                                Ответить
                                              • 1. Речь идет о количестве кода, который нужно написать. ORM позволяет писать меньше кода (в общем случае) ценою более тяжелых запросов. Далее находится боттлнек и переписывается на чистый SQL.

                                                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 это объект или ассоциативный массив?
                                            Ответить
                                            • В Вашем случае разницы никакой (если не считать помощь от IDE, которая иногда бывает более чем полезной).

                                              Просто иногда шаблон хочет форматировать даты, например.
                                              И тогда ему важно знать что в поле birthday лежит дата.

                                              Другой вариант это Ящик Пандоры в шаблонах:
                                              <strong>{{ user.birthday.day}}</strong>


                                              Хотя конечно в идеальном мире всё это должно хендлится уровнем выше (во вьюшках в терминах джанги например) и в шаблонизатор может смело приезжать string-string.

                                              Но опять же: где-то же должны эти преобразования происходить. Если не в модели, то во вьюхе. Ну а худые модели и толстые вьюхи/контроллеры все равно приведут к копи-пасте
                                              Ответить
                                              • <strong>{{ user.birthday|date('d') }}</strong>

                                                Вьюха тут должна хардкодить однозначно. Вьюху вы передаете верстальщику - это его дело, как дату представлять.
                                                Ответить
                                                • бррр... да я в терминах запутался )
                                                  ну короче в шаблон передаем чистую дату, не стринг, я это имел ввиду.

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

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

                                                Думаю вот как-то так выводим автоматическую форму (примитивно, конечно):

                                                <form class="form-horizontal">
                                                {% for key, property in properties %}
                                                <div class="form-group">
                                                        <label for="{{ key }}" class="col-sm-2 control-label">property.label</label>
                                                
                                                        <div class="col-sm-10">
                                                            {{ attribute(item, key)|input(property, key) }}
                                                        </div>
                                                    </div>
                                                {% endfor %}
                                                </form>


                                                где input - это колбэк (живет скорее всего во вьюхе, как у вас в терминах пытхона, ну или в контроллере), он по переданным параметра генерит хтмл с нужным инпутом (пихает параметры в нужный шаблон для инпута и отдает отрендеренный результат).
                                                properties - могут быть сгенерированы впринципе автоматом из модели (по дефолту) и пофичены во вьюхе или контроллере, а могут и в базе лежать, как метданные. В любом случае и для метаданных орм не является необходимым.

                                                И еще заметьте одну штуку. Типы полей в базе - это не одно и тоже, что типы полей на форме, они не всегда мапятся один-в-один.
                                                Ответить
    • Ребят, я, конечно, всё понимаю, но меня заебали сообщения на мыло.
      Ответить
      • так отключи уведомления в настройках
        Ответить
      • Или настрой фильтр в мыльнице.
        Ответить
      • Я в своём ящике создал папку Говнокод для приёма входящих сообщений от отправителя *@govnokod.ru и... заглядываю в неё изредка. То есть почти никогда.
        Ответить
        • У меня такой же фильтр. Захожу только личку почитать.
          Ответить
          • А я пользуюсь чужим аккаунтом и бед не знаю!
            Ответить
            • Воспользовался твоим аккаунтом, проверь
              Ответить
              • Проверил, пароли от моих аккаунтов надежны и в паблик не утекали.
                Ответить
            • Я вообще с майлинатора сидел первое время. А потом мне прострелили колено аватарку захотелось поставить.
              Ответить
              • То есть ты ненастоящий Борманд?
                Ответить
                • Настоящий, просто мыло попросил поменять.
                  Ответить
      • Заебали?
        Ответить
      • Да похуй
        Ответить
    • MZ H4 30W 1500Lm 6500K 6 x XT - E LED Cool White LED Car High / Low Beam Lamp ( Constant Current )


      Long Sleeve Geometric Print Chiffon Blouse
      Long Sleeve Geometric Print Chiffon Blouse
      https://lenkmio.com/g/2316b8f856c30691751022af2ed61b/?i=5&amp;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&amp;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/parser_2gis>2gis parser 4 0 активатор</a>. Вы хотите купить граббер или базу e-mail оптово-розничных магазинов? Тогда вы попали туда, куда нужно!

      На страницах Интернет-магазина вы сможете найти парсеры и грабберы для Интернет-торговли, приобрести информацию с базами контактов и 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>. Вложенные данным образом средства помогут повысить вашу прибыль на порядок!
      Ответить

    Добавить комментарий