Пыхотред

А в чём проблема написать <?=e( $var )?> или что-то в этом роде? Чем принципиально отличается {{ от <?=e(

В подходе и результате по умолчанию. Человек может забыть обернуть значение в e().

Более того, на ревью, когда видишь <?=$var?> не всегда быстро понятно - ошибка ли это и человек просто забыл обернуть в e() или же намеренно выводятся сырые данные. В твиге с {{ var }} и {{ var |raw }} все кристально ясно.

Посмотри как сделано в пресловутом wordpress.

Желания лезть в wordpress никакого. Выше было сказано, что такая возможность есть в php изкоробки. Значит она должна реализовыватся в пару строчек.

Вдумайся в абсурдность ситуации: высокоуровневый DSL для работы с реляционными данными оборачивают низкоуровневой императивной лапшей

тут еще такой момент есть. SQL стандартизирован и большинство реализаций придерживаются стандарта. А ОРМ-ов вагон и маленькая тележка. Что это значит:
1) упрощение миграции на другие языки.
2) разобраться со стандартизированным и удобным SQL проще, чем с кучей ORM-ов.
3) ORM - это лишняя зависимость от сторонней библиотеки и настроения ее разработчиков.
4) есть много практик удобной работы с SQL типа централизованого хранилища запросов, обработки параметров и мапинга в удобные объекты на уровне стандартной библиотеки языка.
5) с ORM ты теряешь много специфичных для SQL плюшек.
6) проблема писать SQL руками сильно упрощается хорошим редактором SQL. Для меня тут идеален IBExpert.

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

Чушь какая. С продвинутой ORM типа sqlalchemy ты никаких плюшек не теряешь.

Как насчет моделей, миграций, генераторов форм и валидаторов для них, сериализаторов для api, генераторов админок. Это всё руками будешь делать и все запросы для этого руками писать?

Человек может забыть обернуть значение в e().

Нет, не может. Он может об этом только не знать.

В твиге с {{ var }} и {{ var |raw }} все кристально ясно.

В чистом пыхе с <?=e( $var )?> и <?= $var ?> тоже всё кристально ясно.

С продвинутой ORM типа sqlalchemy ты никаких плюшек не теряешь.

ты хочешь сказать, что оракел лохи покупают, даешь SQLite во все поля?

Миграции не ORM специфичная вещь.
Модели, формы, админки - ты в контексте работы с СУБД или больше про web?

http://docs.sqlalchemy.org/en/latest/dialects/oracle.html

Миграции с ORM генерируются по большей части автоматически. Иногда надо что-то подравить или дописать миграции данных.

Модели и валидация - вообще СУБД. Формы ес-но для веб.

Чего ты вообще прицепился? Меня спросили что умеют шаблонизаторы, но не умеет пых.

А пых не умеет из коробки автоэскейпинг и наследование шаблонов.

С продвинутой ORM типа sqlalchemy ты никаких плюшек не теряешь.

Эту хрень дольше изучать, чем сам оракл. А потом нужно еще набить руку, чтобы писать на нем вырвиглазные запросы. Вернее происходит все так: пишешь и отлаживаешь запрос на замшелом SQL, потом чешешь репу как его натянуть на очередной молодежный орм. Для простейшего круда оно может и удобней, а зачем тогда «продвинутый» орм?

Миграции пишутся тоже на SQL, в чем проблема? SQL это не только select * from foo.

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

Модели прибиваешь гвоздями к таблицам? Только чудаки так делают, и выгребают потом триппер.

http://docs.sqlalchemy.org/en/latest/dialects/oracle.html

я не про то. Я про всякие триггеры, хранимки и т.д.

Миграции с ORM генерируются по большей части автоматически

для этого придумана куча инструментов. Как бы не проблема.

Модели и валидация - вообще СУБД

Опять же, что имеется в виду: модели СУБД - иерархическая, реляционная и прочая, или таблички с разнообразными констрейнтами? Я с алхимиком не работал, но после беглого гуглежа я понял, что это именно про автоматизацию работы с табличками. Так?

Формы ес-но для веб.

И к чему смешивать ORM и веб?

Я про всякие триггеры, хранимки и т.д.

ОРМ не мешает этим пользоваться.

модели СУБД - иерархическая, реляционная и прочая

Все связи ты описываешь через ОРМ, можешь с ними работать как с объектами, указывать в запросах, всякие деревья тоже поддерживаются, например https://github.com/uralbash/sqlalchemy_mptt

Можешь генерить модели для уже существующих таблиц тоже.

модели

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

И к чему смешивать ORM и веб?

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

ОРМ не мешает этим пользоваться.

Хм, но тогда он лишняя сущность - тупо проще иметь дело с одной концепцией.

Все связи ты описываешь через ОРМ

1) почитай, что такое модели СУБД.
2) Все это чудесно делается и через стандартный (в рамках используемой СУБД) SQL. Более того, полно удобных инструментов для работы непосредственно с СУБД с версионированием и т.д.

Это скорее про классы, на которые отображаются таблицы.

Так отношения (они же, на жаргоне, таблицы) есть не что иное, как модель предметной области. Где-то как классы в ООП. Алхимик отображает питоньи классы в сущности лежащей под ним СУБД. То-есть выступает такой себе СУБД над СУБД. Но тогда концептуально проще и практичнее иметь дело с одной СУБД :).

начинается подгонка схемы под эти модели или наоборот танцы вокруг моделей

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

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

т.е. ORM используют как улучшеный SQL, оставляя суть той самой. Я правильно тебя понял?

автоэскейпинг

Да нет никакого автоэскейпинга, это маркетинговый булшит. Есть более удобная запись для эскейпинга. Да в твиге для этого меньше буков, но не более того.

наследование шаблонов

Это вообще организационная вещь. Можно и на твиге написать так, что хрен унаследуешь.

Чего ты вообще прицепился?

Потому что ты задал вопрос Пыхотред (комментарий) и стал фантазировать на темы, о которых ты имеешь очень поверхностное представление, полученное из рекламных агиток.

Да нет никакого автоэскейпинга, это маркетинговый булшит. Есть более удобная запись для эскейпинга. Да в твиге для этого меньше буков, но не более того.

Есть автоэскейпинг. В твиге с включенным автоэскейпингом принципиально невозможно забыть заэскейпить переменную. Т.к. вывод значения сразу же сочетается с эскейпингом. <?= ?> в пыхе такой особенностью не обладает.

Это вообще организационная вещь. Можно и на твиге написать так, что хрен унаследуешь.

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

Потому что ты задал вопрос

И самое забавное, что прямого ответа на этот вопрос я так и не увидел.

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

А вот тут мимо, я довольно долго пользовался твигом

ORM позволяет мыслить в предметной области решаемой задачи, а не в предметной области её реализации (для ООП языков)

принципиально невозможно забыть заэскейпить переменную

Возможно. Написав {{ $var|raw }}. Например потому что эскейпинг требует времени и некто может везде писать этот |raw. Ты можешь сказать, что этот некто - дебил. Тогда я отвечу, что человек который забывает эскейпить в php тоже дебил. Очень странно разрабатывать инструмент в расчёте на дебилов (ну разве что для военного применения).

не написав свой псевдошаблонизатор ты эффективно так наследоватся не сможешь

Я тебя уже ткнул носом в WP где никакого «своего псевдошаблонизатора» нет, а ты всё равно продолжаешь отрицать реальность.

прямого ответа на этот вопрос я так и не увидел

Всё ты увидел.

я довольно долго пользовался твигом

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

Мне удобней писать на языке, на котором я пишу, чем SQL. Например у меня manytomany связь entity - user, вместо

SELECT * FROM "auth_user" INNER JOIN "business_entity_users" ON ("auth_user"."id" = "business_entity_users"."user_id") WHERE ("business_entity_users"."entity_id" = (SELECT id from "entity" WHERE name="ЯНДЕКС") AND "auth_user"."username" = ph)

Я пишу

Entity.objects.get(name='ЯНДЕКС').users.filter(username='ph')

Получаю объект User, в котором я могу что-то изменить и сделать .save() вместо того чтобы ручками писать update.

ORM позволяет мыслить в предметной области решаемой задачи

Отношения, на жаргоне «таблицы», тоже моделируют предметную область.

Проблема только в том что написание sql руками ведёт к довольно монстроуозному коду когда нужно конструировать sql по условиям.

Шаблоны. Да-да, можно прямо встраивать этот ваш похапе. По шаблону не только html можно генерить, для вебельщиков это похоже неочевидно. Ну и тяжелая артиллерия - хранимки.

То-есть выступает такой себе СУБД над СУБД. Но тогда концептуально проще и практичнее иметь дело с одной СУБД

Именно. Все аргументы ормо-фанатов сводятся к одной идее: не хотим писать SQL. Все остальное чепуха. Но от SQL им никуда не деться все равно, он гад такой вылазит постоянно и норовит укусить. Приходится знать и SQL и пачку ормов.

«таблицы», тоже моделируют предметную область

Это утверждение из разряда «brainfuck - Тьюринг полный язык, поэтому всё можно делать на brainfuck».

SQL, конечно, далеко не эталон читабельности и лаконичности, но такой вариант несколько лучше:

SELECT * FROM auth_user u
JOIN business_entity_users b ON u.id = b.user_id
JOIN entity e ON b.entity_id = e.id
WHERE e.name='ЯНДЕКС' AND u.username = 'ph'

Шаблоны. Да-да, можно прямо встраивать этот ваш похапе.

там и без шаблонов геммороя хватает. Yравится - используй шаблоны и хранимки. Девиации бывают разные: кому-то php нравится, кому-то лисп, кому-то языки на кириллице, кому-то хранимые процедуры и sql. Я это оставлю без комментариев, пожалуй.

вместо ... Я пишу

Т.е. ты всегда отслеживаешь во что именно оттранслируется цепочка методов? Или тебе пофиг, пусть что хочет делает? А он такой вместо джойнов тебе выгребет n+1 запросов. Или наоборот, там где лучше бы джойнов избежать, соединит 10 таблиц.

Это утверждение из разряда

Вообще-то ORM - это то же самое отношение, вид сбоку. И единственный его плюс - более читабельный синтаксис (с этим не спорю)

Ну, в джанге можно нажать кнопочку и оно тебе покажет какие запросы выполнились на странице и сколько времени они занимали. https://raw.github.com/jazzband/django-debug-toolbar/master/example/django-de...

Поведние будут ли джоины или много запросов определяется наличием всяких select_related / prefetch_related.

В алхимии можно вообще можно явно это всё указывать.

А что плозого в SQL? Неужели корявая лапша на похапе лучше?

А что плозого в SQL? Неужели корявая лапша на похапе лучше?

я не знаю как это правильно сформулировать навскидку, но в общем - плохо то что он «не в тему». Может быть лапша на php не лучше чем лапша на sql. Но штука в том что на php можно написать не-лапшу. А вот на sql принципиально нет.

Все там можно, было бы желание. Просто SQL неимперативный, это самая главная проблема кодеров. Хотя в вебе сильно сложных то запросов не бывает, да и хрен ты их запишешь средствами орма. То предлагают в строки засовывать фрагменты SQL, то вообще сдаются и посылают писать сырые запросы.

да и хрен ты их запишешь средствами орма.

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

Все там можно, было бы желание. Просто SQL неимперативный, это самая главная проблема кодеров

Наверное. Пример есть выше, Taxo1 дал на sql, я переписал на ORM. Давай свой пример, как бы сделал ты, без лапши. Поглядеть любопытно.

Именно. Все аргументы ормо-фанатов сводятся к одной идее: не хотим писать SQL.

Надо сказать, что эта идея не нова. Однако, уже во второй половине 90-х, поддержка SQL была почти во всех живых инструментах разработки для СУБД. Я тоже, когда-то, не хотел в SQL. Но оказалось целесообразнее выучить.

Давай свой пример, как бы сделал ты, без лапши

Я выше давал SQL vs ORM. Не лапша, читаемо и видно связи. Хотя и многословней, с этим не спорю. Но многословность легче пережить, чем неочевидность ORM.

Возможно. Написав {{ $var|raw }}.

Забыть заэскейпить - невозможно. Ключевое слово - забыть. {{ var|raw }} нужно делать целенаправленно.

Я тебя уже ткнул носом в WP где никакого «своего псевдошаблонизатора» нет.

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

Я понимаю, что дальше твига ты продвинуться не смог.

И опять ты вангуешь неверно.

Я тебя уже ткнул носом в WP где никакого «своего псевдошаблонизатора» нет

Все что я бегло нашел в доках wp это следущее.

<?php get_header(); ?>
<?php get_template_part('nav'); ?>
<h2>Error 404 - Not Found</h2>
<?php get_sidebar(); ?>
<?php get_footer(); ?>

Тут нет псевдошаблонизатора, но и нет того типа наследования, которое было у меня в вопросе.

Использование orm не озночает, что ты не должен знать sql и понимать как оно работает. Обычно к использованию orm приходят уже когда знают sql.

неочевидность ORM.

Никакой неочевидности нет.

см. выше. Из твоего ORM кода сходу не поймешь, что там реально задействовано.

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

Дай пример кода

<?php ob_start(); ?>
    Content of the page...
<?php $content = ob_get_clean(); ?>

<?php require 'layout.php' ?>

После твига наверное магия.

Ключевое слово - забыть

Давай так, ты сам лично когда-нибудь забывал? Я видел примеры когда на это забивали (или не знали), но чтобы забывали - никогда.

Получаю объект User, в котором я могу что-то изменить и сделать .save()

Проблема многих ORM в том, что они реализуют только вещи, которые общие для разных баз. И поэтому невозможно выполнить SELECT ... FOR UPDATE на MySQL базе, например.

Давай так, ты сам лично когда-нибудь забывал?

Да, когда только начинал такое было.

Я видел примеры когда на это забивали (или не знали), но чтобы забывали - никогда.

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

После твига наверное магия.

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

Ну и с точки зрения удобства ситуация, когда наследование располагается в самой жопе - не совсем удобно.

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

В твоем примере будет одно из двух, в зависимости от того, что там в layout.php

Да ты просто лалка. Любой школоло прочитавший книжку «php за 24 часа» допетрит, что нужно сделать чтобы реализовать то, что ты хочешь за 5 минут. Например иметь отдельно defaults.php с дефолтным значением $contents и подключать его require_once, а в шаблоне писать $contents .= 'add' и т.п. Причем это всё будет уже в разы функциональнее твига, потому что $contents можно крутить как угодно средствами php, а не урезанным микроязыком шаблонизатора.