Я бы сказал так.
Для «классического похапе» это действительно прекрасный шаблонизатор. Сделать автоискейпинг на этапе задания переменных шаблона совсем несложно, если в шаблон не передаются объекты.
Если же это современный код, где в шаблон передаются объекты с виртуальными свойствами, то чтобы сделать хороший автоискейпинг, надо наворотить кода не меньше, чем понадобится для небольшого шаблонизатора. При этом автоискейпинг — это стопроцентный маст-хэв, вещь, без которой в принципе нельзя.
Плюс такие вещи, как наследование в нативном пхп делаются не так чтобы просто.
И что с того?
Если прям так хочется на вершину — программирование далеко не лучший выбор профессии. Надо идти в финансисты, управленцы, юристы, политики.
Но лично я не понимаю, что там (на вершине) делать.
Программирование — это скорее для человека, который хочет получать деньги за занятие своим хобби, заниматься творчеством. А не скакать по лестницам.
Да и в целом эта проблема не слишком релевантна географии. Если у человека главная проблема в жизни — сколько зарабатывает его сосед, то ему везде будет некомфортно. Ну разве что в Африку уехать.
И всё же, «Силиконовая долина» — неправильно. Силиконовые бывают сиськи. А долина — Кремниевая.
Silicon и Silicone — это два разных слова. Если по-английски они звучат одинаково, это не повод коверкать название в русском. Надо уважать свой язык. В нём кремний и силикон — это разные слова. Точно так же как барак и казарма, милиция и ополчение, амуниция и боеприпасы. Переводя какой-либо термин, надо руководствоваться его значением, а не произношением.
Пожалуйста, не надо путать правильный вариант с привычным. Пусть «Вам сыр послайсать или писом брать будете?» и звучит привычно для эмигрантского уха, но это суржик, а не русский язык. Никто не называет этот вариант правильным.
Более корректной формулировкой было бы «Я знаю, что „силиконовая“ — неправильно, но калька проще и привычней».
Я ничего удивительного в этом не вижу. Write-only языки и подходы шагают по планете.
Ширпотреб вытесняет вещь. Машина делается со сроком службы три года, гаджет — полгода. Почему программа должна работать дольше? Написал шустренько — и в продакшен. А если что-то сломалось, то проще новую написать, чем со старой разбираться.
NikiC совсем заигрался. Всякий раз, когда я буду видеть вызов вида foo()() — я буду от всей души желать написавшему это гореть в аду.
Прелесть РНР всегда была в читабельности кода — читать код было почти так же легко, как и писать. То есть, поклонники стиля «фигак-фигак — и на продакшен» не могли сильно поднагадить тем, кто будет после них отлаживать код. Но в последние годы сообщество серьёзно работает над тем, чтобы окончательно похоронить читабельность.
а этого Andrea Faulds я затопчут свои же, я надеюсь
Ага, сам нашел. Сейчас только мускуль и лайт.
То есть, в данным момент единый интерфейс для доступа к любым БД — скорее желательное, чем действительное.
Но, вообще, при наличии достаточного количества драйверов, идея сделать ПДО единственным интерфейсом для работы с любыми БД, просто бай дезигн, не лишена смысла. Что-то в этом есть.
Во-первых, не плеера, а деки. Я понимаю, что несколько старомоден в своих аналогиях, но уж что первое в голову пришло :)
Во-вторых, как раз магнитола, представляющая собой комбайн из нескольких устройств, и является аналогом PDO. При этом каждое из устройств у комбайне справляется со своей задачей чуть хуже, чем специализированное.
В-третьих, аналогии вообще зло. Главное, что по остальным пунктам возражений нет :)
Кстати, про общую систему доступа к бд через кучу драйверов. Интересно, как у HHVM с драйверами?
Вы оба не совсем понимаете, что такое mysqli. Отвечу сразу обоим.
Ничего «старого» в технологии mysqli нет. Как и «нового» в PDO. И объективностью тут даже не пахнет.
Нельзя сравнивать профессиональную кассетную деку с портативной магнитолой, и заявлять о превосходстве последней только потому что ее можно взять с собой на шашлыки.
mysqli — это просто тончайшая обертка над C API. Из этого следуют ее плюсы и минусы.
Плюсы в том, что она реализует весь функционал API. А это несколько более широкий диапазон задач, чем «послать запрос-получить ответ». mysqli позволяет такие вещи, про которые в ПДО и слыхом не слыхивали: пинг, асинхронные запросы, низкоуровневый дебаг на уровне соединения и много других фич, о существовании которых пользователи «старой технологии» (шарашить функциями API прямо в коде приложения) даже не догадываются. И реализуется это всё без оглядки на необходимость соблюдения совместимости с остальными 100500 драйверами в колхозе.
Минусы тоже очевидны — обращение к низкоуровневым API всегда получается более трудоемким. Ну так для этого и существуют врапперы. Я конечно понимаю, что средний пользователь похапешечки способен пользоваться только тем, что дают, причем только в стандартной поставке языка. В этом случае PDO рулит безальтернативно, поскольку представляет из себя как раз недо-DAL, реализуя некоторые функции враппера. При наличии же рук, растущих из нужного места, и потребностей, чуть выходящих за рамки «SELECT * FROM users WHERE id=$id», сделать из mysqli инструмент столь же удобный, как PDO, не составляет проблемы.
Просто надо отказаться от этой дурацкой идеи, что низкоуровневое API предназначено для использования в коде приложения. Из той же «устаревшей технологии mysql API» Дима Бородин ещё в прошлом веке делал конфетку в виде одной-единственной функции для выполнения запросов к базе, с коннектом по требованию, экранированием и возвращением готового результата. Было бы желание.
С этой точки зрения, кстати, «голый» PDO — такой же анахронизм. В коде должны быть обращения к методам модели. В крайнем случае — враппера DB. Какой там драйвер лежит под ними — дело десятое.
Скажем прямо, для этого текста никакой лички не хватит.
«Переписанный» вариант оказался чуть ли не хуже изначального.
Тут, правда, не в грамматике дело — переводчик попросту не знает языка, на который взялся переводить.
Это-то и ужасно.
Ага, оно работает, и даже с методами (надо поправить опечатку в вызове call_user_func_array()).
Но беда в том, что принцип рекурсии, который распространяется на остальные типы, не распространяется на объекты. И если со свойством ещё можно как-то извернуться, то с методом, который возвращает массив — уже, кажется, никак… :(
А у меня, в моей практической задаче, есть, к примеру, у юзера свойство $geo, которое само объект, который не инициализирован изначально, а тянется только когда вызван. В общем, я пока бросил эту затею.
Ну я ж об этом и говорю — надо. Надо указывать контекст.
Но нам важно, чтобы даже и без указания контекста, выводимая переменная если уж не принесла пользы — то хотя бы не навредила. Я об этом выше и говорил. С тем, что надо указывать контекст, никто не спорит.
Я тупанул выше.
В «шаблонизаторах» мы как раз имеем inline-форматирование, когда фильтр накладывается уже перед самым выводом, и прописывается прямо в шаблоне. Так что да — в этом смысле шаблонизатор удобнее нейтива — о чем я и говорил, начиная эту ветку.
Но проблема с «конями», ей-богу — не самая большая у нейтива. Наложить фильтр эксплицитно — не проблема. Главная проблема — всё-таки, накладывание дефолтного фильтра.
Ну вот, к сожалению, в HTML я не очень силён, моя идея происходит от обработки параметров в SQL, где это работает 100%.
Но вообще, если говорить о выводе в HTML, то если любые спецсимволы конвертировать в HTML-сущности, то проблемы близости к оригиналу быть не должно, вроде бы.
Не понял, при чем здесь противопоставление «нейтив — шаблонизаторы».
Очевидно же, что разговор здесь идет о шаблонизаторах вообще, любых.
Все описанные выше принципы относятся к «шаблонизаторам» в той же самой мере. В них точно так же должна быть поддержка фильтров, которая должна иметь ту или иную внутреннюю реализацию. Вот варианты реализации фильтров мы и обсуждаем здесь.
На момент вызова tmpl::set() мы вообще не знаем, какой конкретно синтаксис в шаблонизаторе используется — нейтив или самопал. И не должны знать, по-хорошему.
Ну, это уже вкусовщина. У кого-то от угловых рябит, у кого-то — от фигурных.
А по поводу остальных фич — надо различать РНР как язык разметки шаблонов и Шаблонизатор как модуль приложения. Чистый PHP не означает «чисто include()» как обработчик шаблонов — такой обработчик все равно пишется специально. и в нем уже можно реализовать и наследование и многие другие вкусности
Я думаю, в хорошем приложении наборов должно быть больше.
«неэскейпенные» — это, на самом деле, частный случай, один из фильтров.
Но фильтров может быть много — urlencode, JSON к примеру.
Для «классического похапе» это действительно прекрасный шаблонизатор. Сделать автоискейпинг на этапе задания переменных шаблона совсем несложно, если в шаблон не передаются объекты.
Если же это современный код, где в шаблон передаются объекты с виртуальными свойствами, то чтобы сделать хороший автоискейпинг, надо наворотить кода не меньше, чем понадобится для небольшого шаблонизатора. При этом автоискейпинг — это стопроцентный маст-хэв, вещь, без которой в принципе нельзя.
Плюс такие вещи, как наследование в нативном пхп делаются не так чтобы просто.
Если прям так хочется на вершину — программирование далеко не лучший выбор профессии. Надо идти в финансисты, управленцы, юристы, политики.
Но лично я не понимаю, что там (на вершине) делать.
Программирование — это скорее для человека, который хочет получать деньги за занятие своим хобби, заниматься творчеством. А не скакать по лестницам.
Да и в целом эта проблема не слишком релевантна географии. Если у человека главная проблема в жизни — сколько зарабатывает его сосед, то ему везде будет некомфортно. Ну разве что в Африку уехать.
И всё же, «Силиконовая долина» — неправильно. Силиконовые бывают сиськи. А долина — Кремниевая.
Silicon и Silicone — это два разных слова. Если по-английски они звучат одинаково, это не повод коверкать название в русском. Надо уважать свой язык. В нём кремний и силикон — это разные слова. Точно так же как барак и казарма, милиция и ополчение, амуниция и боеприпасы. Переводя какой-либо термин, надо руководствоваться его значением, а не произношением.
Пожалуйста, не надо путать правильный вариант с привычным. Пусть «Вам сыр послайсать или писом брать будете?» и звучит привычно для эмигрантского уха, но это суржик, а не русский язык. Никто не называет этот вариант правильным.
Более корректной формулировкой было бы «Я знаю, что „силиконовая“ — неправильно, но калька проще и привычней».
Ширпотреб вытесняет вещь. Машина делается со сроком службы три года, гаджет — полгода. Почему программа должна работать дольше? Написал шустренько — и в продакшен. А если что-то сломалось, то проще новую написать, чем со старой разбираться.
Прелесть РНР всегда была в читабельности кода — читать код было почти так же легко, как и писать. То есть, поклонники стиля «фигак-фигак — и на продакшен» не могли сильно поднагадить тем, кто будет после них отлаживать код. Но в последние годы сообщество серьёзно работает над тем, чтобы окончательно похоронить читабельность.
а этого Andrea Faulds я затопчут свои же, я надеюсь
То есть, в данным момент единый интерфейс для доступа к любым БД — скорее желательное, чем действительное.
Но, вообще, при наличии достаточного количества драйверов, идея сделать ПДО единственным интерфейсом для работы с любыми БД, просто бай дезигн, не лишена смысла. Что-то в этом есть.
Во-вторых, как раз магнитола, представляющая собой комбайн из нескольких устройств, и является аналогом PDO. При этом каждое из устройств у комбайне справляется со своей задачей чуть хуже, чем специализированное.
В-третьих, аналогии вообще зло. Главное, что по остальным пунктам возражений нет :)
Кстати, про общую систему доступа к бд через кучу драйверов. Интересно, как у HHVM с драйверами?
Ничего «старого» в технологии mysqli нет. Как и «нового» в PDO. И объективностью тут даже не пахнет.
Нельзя сравнивать профессиональную кассетную деку с портативной магнитолой, и заявлять о превосходстве последней только потому что ее можно взять с собой на шашлыки.
mysqli — это просто тончайшая обертка над C API. Из этого следуют ее плюсы и минусы.
Плюсы в том, что она реализует весь функционал API. А это несколько более широкий диапазон задач, чем «послать запрос-получить ответ». mysqli позволяет такие вещи, про которые в ПДО и слыхом не слыхивали: пинг, асинхронные запросы, низкоуровневый дебаг на уровне соединения и много других фич, о существовании которых пользователи «старой технологии» (шарашить функциями API прямо в коде приложения) даже не догадываются. И реализуется это всё без оглядки на необходимость соблюдения совместимости с остальными 100500 драйверами в колхозе.
Минусы тоже очевидны — обращение к низкоуровневым API всегда получается более трудоемким. Ну так для этого и существуют врапперы. Я конечно понимаю, что средний пользователь похапешечки способен пользоваться только тем, что дают, причем только в стандартной поставке языка. В этом случае PDO рулит безальтернативно, поскольку представляет из себя как раз недо-DAL, реализуя некоторые функции враппера. При наличии же рук, растущих из нужного места, и потребностей, чуть выходящих за рамки «SELECT * FROM users WHERE id=$id», сделать из mysqli инструмент столь же удобный, как PDO, не составляет проблемы.
Просто надо отказаться от этой дурацкой идеи, что низкоуровневое API предназначено для использования в коде приложения. Из той же «устаревшей технологии mysql API» Дима Бородин ещё в прошлом веке делал конфетку в виде одной-единственной функции для выполнения запросов к базе, с коннектом по требованию, экранированием и возвращением готового результата. Было бы желание.
С этой точки зрения, кстати, «голый» PDO — такой же анахронизм. В коде должны быть обращения к методам модели. В крайнем случае — враппера DB. Какой там драйвер лежит под ними — дело десятое.
«Переписанный» вариант оказался чуть ли не хуже изначального.
Тут, правда, не в грамматике дело — переводчик попросту не знает языка, на который взялся переводить.
Это-то и ужасно.
Но беда в том, что принцип рекурсии, который распространяется на остальные типы, не распространяется на объекты. И если со свойством ещё можно как-то извернуться, то с методом, который возвращает массив — уже, кажется, никак… :(
А у меня, в моей практической задаче, есть, к примеру, у юзера свойство $geo, которое само объект, который не инициализирован изначально, а тянется только когда вызван. В общем, я пока бросил эту затею.
Но работать не будет.
Разработчики будут по умолчанию лепить контекст «HTML» и пропускать JS-инъекции.
Чем я сейчас и занимаюсь. Это ж ведь не языком чесать — тут время нужно :)
Но нам важно, чтобы даже и без указания контекста, выводимая переменная если уж не принесла пользы — то хотя бы не навредила. Я об этом выше и говорил. С тем, что надо указывать контекст, никто не спорит.
В «шаблонизаторах» мы как раз имеем inline-форматирование, когда фильтр накладывается уже перед самым выводом, и прописывается прямо в шаблоне. Так что да — в этом смысле шаблонизатор удобнее нейтива — о чем я и говорил, начиная эту ветку.
Но проблема с «конями», ей-богу — не самая большая у нейтива. Наложить фильтр эксплицитно — не проблема. Главная проблема — всё-таки, накладывание дефолтного фильтра.
Но вообще, если говорить о выводе в HTML, то если любые спецсимволы конвертировать в HTML-сущности, то проблемы близости к оригиналу быть не должно, вроде бы.
Очевидно же, что разговор здесь идет о шаблонизаторах вообще, любых.
Все описанные выше принципы относятся к «шаблонизаторам» в той же самой мере. В них точно так же должна быть поддержка фильтров, которая должна иметь ту или иную внутреннюю реализацию. Вот варианты реализации фильтров мы и обсуждаем здесь.
На момент вызова tmpl::set() мы вообще не знаем, какой конкретно синтаксис в шаблонизаторе используется — нейтив или самопал. И не должны знать, по-хорошему.
А по поводу остальных фич — надо различать РНР как язык разметки шаблонов и Шаблонизатор как модуль приложения. Чистый PHP не означает «чисто include()» как обработчик шаблонов — такой обработчик все равно пишется специально. и в нем уже можно реализовать и наследование и многие другие вкусности
«неэскейпенные» — это, на самом деле, частный случай, один из фильтров.
Но фильтров может быть много — urlencode, JSON к примеру.