LINUX.ORG.RU

Пыхотред

 


1

5

А чего это у нас, в нашем загончике, нет закрепленного пыхотреда?

Вот теперь есть(надеюсь, его закрепят).

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

В тред приглашаются все пыхобоги, пыходемоны, пыхофрилансеры, простые пыхари, и даже пыхоненавистники.

Обсудить есть много чего, начиная с различий версий, особенностей языка, CMS-ок, фреймворков, и заканчивая говнокодом.

<?php

Ответ на: комментарий от no-such-file

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

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

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

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

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

aiive ()
Ответ на: комментарий от anonymous

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

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

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

cab ★★★★ ()
Последнее исправление: cab (всего исправлений: 1)
Ответ на: комментарий от cab

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

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

pawnhearts ★★★★ ()
Ответ на: комментарий от aiive

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

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

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

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

no-such-file ★★★★★ ()
Ответ на: комментарий от pawnhearts

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

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

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

cab ★★★★ ()
Ответ на: комментарий от cab

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

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

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

pawnhearts ★★★★ ()
Ответ на: комментарий от no-such-file

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

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

aiive ()
Ответ на: комментарий от pawnhearts

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

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

anonymous ()
Ответ на: комментарий от pawnhearts

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

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

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

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

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

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

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

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

cab ★★★★ ()
Последнее исправление: cab (всего исправлений: 1)
Ответ на: комментарий от cab

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

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

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

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

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

pawnhearts ★★★★ ()
Последнее исправление: pawnhearts (всего исправлений: 1)
Ответ на: комментарий от cab

модели

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

anonymous ()
Ответ на: комментарий от cab

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

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

anonymous ()
Ответ на: комментарий от pawnhearts

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

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

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

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

cab ★★★★ ()
Ответ на: комментарий от anonymous

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

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

cab ★★★★ ()
Последнее исправление: cab (всего исправлений: 2)
Ответ на: комментарий от anonymous

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

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

pawnhearts ★★★★ ()
Ответ на: комментарий от cab

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

AndreyKl ★★★★★ ()
Последнее исправление: AndreyKl (всего исправлений: 1)
Ответ на: комментарий от aiive

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

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

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

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

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

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

no-such-file ★★★★★ ()
Последнее исправление: no-such-file (всего исправлений: 1)
Ответ на: комментарий от no-such-file

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

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

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

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

aiive ()
Ответ на: комментарий от no-such-file

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

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

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

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

aiive ()
Ответ на: комментарий от aiive

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

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

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

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

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

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

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

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

no-such-file ★★★★★ ()
Ответ на: комментарий от cab

Мне удобней писать на языке, на котором я пишу, чем 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.

pawnhearts ★★★★ ()
Ответ на: комментарий от AndreyKl

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

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

anonymous ()
Ответ на: комментарий от cab

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

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

anonymous ()
Ответ на: комментарий от pawnhearts

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'

1) Однако, из ORM-кода не поймешь, что, собственно, задействовано выборке. Надо лезть в потроха объектов, чтобы понять, как там связаны 3 таблицы. Без SQL я бы считал, что таблиц там 2. Т.е. налицо усложнение поддержки
2) Сгенерированный SQL потенцально (а на некоторых СУБД - реально) менее производительный из-за встроеного запроса.

cab ★★★★ ()
Последнее исправление: cab (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

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

AndreyKl ★★★★★ ()
Последнее исправление: AndreyKl (всего исправлений: 1)
Ответ на: комментарий от pawnhearts

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

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

anonymous ()
Ответ на: комментарий от no-such-file

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

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

cab ★★★★ ()
Ответ на: комментарий от anonymous

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

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

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

pawnhearts ★★★★ ()
Ответ на: комментарий от anonymous

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

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

AndreyKl ★★★★★ ()
Ответ на: комментарий от AndreyKl

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

pawnhearts ★★★★ ()
Ответ на: комментарий от anonymous

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

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

AndreyKl ★★★★★ ()
Ответ на: комментарий от anonymous

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

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

cab ★★★★ ()
Ответ на: комментарий от AndreyKl

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

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

cab ★★★★ ()
Последнее исправление: cab (всего исправлений: 1)
Ответ на: комментарий от no-such-file

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

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

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

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

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

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

aiive ()
Ответ на: комментарий от no-such-file

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

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

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


Тут нет псевдошаблонизатора, но и нет того типа наследования, которое было у меня в вопросе.
aiive ()
Ответ на: комментарий от cab

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

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

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

pawnhearts ★★★★ ()
Ответ на: комментарий от pawnhearts

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

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

cab ★★★★ ()
Последнее исправление: cab (всего исправлений: 2)
Ответ на: комментарий от aiive

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

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

<?php require 'layout.php' ?>

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

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

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

no-such-file ★★★★★ ()
Последнее исправление: no-such-file (всего исправлений: 2)
Ответ на: комментарий от pawnhearts

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

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

aiive ()
Ответ на: комментарий от no-such-file

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

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

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

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

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

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

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

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

aiive ()
Ответ на: комментарий от aiive

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

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

no-such-file ★★★★★ ()
Последнее исправление: no-such-file (всего исправлений: 1)