Что вы имеете в виду под «контейнером зависимостей», применение паттерна DI?
да, это и имеется в виду. я обычно для мелких домашних проектов, которые собираю из разных пакетов, использую https://github.com/auraphp/Aura.Di — простой, легкий и удобный, а еще не тянет кучу всего за собой
еще вопрос — а как экранируете вывод в шаблонах? например тут
с твигом по этому поводу париться бы не пришлось, да и вот такого тоже не было бы
мельком посмотрел и не увидел никакого контейнера зависимостей. что-нибудь подобное используется? и почему вместо твига решили «откатиться» к php-шаблонам?
я бы добавил еще интуитивный багфикс — когда нужно что-то пофиксить в проекте, к которому недавно присоединился. Особенно это чувствуется в проекте без тестов — нужно починить то, не знаю что.
Или же это применимо когда баг не в твоей зоне ответственности, но каким-то чудом знаешь где косяк
Можно было и выполнить ТЗ, и оставить совесть чистой — для этого настройку вариантов ответов и итогового результата вынести в админку, чтоб заказчик сам настроил как ему нужно.
редактировать путь к исходному файлу в маппинге ресурсов
это и имеется в виду. Вдруг разработчик модуля слегка криворукий, а модуль все же полезный, мало ли что может быть. Пока работал с вордпрессом — такое бывало.
А так в gulpfile переписал путь и все, исходный файл не тронут
За советы спасибо, но я наверно не так объяснил что имел в виду — как раз визуальный редактор к примеру не нужен в публичной части сайта, а в админке норм
значит вписывать его в зависимости если он нужен. не нужен — не вписывать. может мне вообще не понадобится оттуда ничего кроме одного куска — в вашем случае все равно подключится то что система посчитает нужным.
мне больше нравится подход чтоб я сам решал когда что подключить и нужно ли оно мне.
Вдруг я захочу вместо скрипта от модуля использовать свой?
Так я вместо скрипта от модуля напишу такс для своего и все, модуль продолжит обновляться, а мои изменения работать как мне нужно
если про фронтэнд — то ничего такого нет в этом — зависимость для модуля так же включаем в gulp-задачу, а на выходе будут склеенные скрипты.
Самый простой случай — разные модули зависят от чего-то одного — например, от загрузчика в админке, для которого свой кусок собирается, и на публичной части сайта — +1 строка в каждую секцию, не особо критично и просто
а если у вас такое в бекэнде модуля — то что-то у вас нечисто
А как там с зависимостями, нужно в повторять подключение множества файлов раз за разом?
такое разруливать самому, но случай какой-то странный.
Например, установка Bower/NPM пакетов с помощью Composer плагина прямо из админки с интерактивным прогрессом
это конечно круто, но я б отнес к разряду «свистелко-перделок».
Если нет ноды на серваке — то закидывать в cvs скомпилленные ассеты и не придется ничего запускать.
Даже если не используется никакая csv — по фтп закинуть скомпилленные файлы будет проще.
Вот есть у меня один модуль, в котором нужно загружать котиков, и второй модуль, который непосредственно реализует загрузку файлов в общем виде.
мы все еще про зависимости фронтэнда или про модули в вашей системе? Если модули в вашей системе — то что-то тут нечисто
в куче модулей.
Даже написание задачи gulp для нужных файлов все равно выйдет короче. Я б на вашем месте сделал gulpfile.js с заданием для скриптов/стилей модулей, которые у вас в комплекте идут, может кому понадобится
мне больше нравится подход как здесь — https://laravel.com/docs/5.3/elixir
И как это совместимо будет с подходом
TypeScript->JavaScript, Less->CSS, SCSS->CSS?
Большинство программистов, которые немного игрались с PHP, знают две вещи про него: это плохой язык, который они никогда не станут использовать при наличии выбора
В любом языке можно найти что-то кажущееся странным, например как тут
сам php вполне себе норм, но вот часть тех, кто на нем пишут — это ппц Х_х. Вроде бы на дворе 2016 год, а на работе в проектах от другой команды до сих пор видны ошибки вида «cannot modify header information — headers already sent» или же ошибки выполнения sql-запросов (вообще только за то, что это видит пользователь на странице, нужно отрывать руки с корнями)
Потому мне кажется, что всех кто связан с php можно разделить на 2 лагеря: староверы — это те, кто работает с 1-2 cms, могут написать под них модуль, при работе с другими системами не могут переключиться на другой подход потому что привыкли, в основном делают сайты-визитки и шаблонные простые интернет-магазины клиентам. Про автоматизированное тестирование не слышали или же считают что проверить вручную будет быстрее. Таких лучше не подпускать к даже немного сложным проектам. Пишут в стиле php4 до сих пор, развитием языка и новыми фишками не интересуются. Код пишется в каком-нибудь notepad++. Деплой — закинуть файлы через фтп и залить дампы новых таблиц через phpmyadmin. приверженцы современного подхода — эти люди чтят psr, работают с современными фреймворками, знают как работает веб-сервер и могут спокойно сами его настроить оптимально в зависимости от проекта. Вполне себе пишут еще на нескольких языках или хотя бы имеют представление о других подходах. Пишут тесты и знают какие они бывают. Стараются использовать последние фишки языка. Для работы используют IDE (phpstorm, netbeans и т.п.). Деплой чаще всего автоматизирован.
Разделение весьма условное, да и промежуточные варианты тоже существуют, но вот сам язык позволяет использовать оба таких подхода — и старый, потому что куча кода написанная ранее должна продолжать работать, и новый, т.к. язык развивается и новые проекты лучше начинать используя последние возможности. Получается, что к php наверно всегда будут относиться с некоторым пренебрежением и презрением из-за староверов и недоучек, которые после установки вордпресса мнят себя обалденными специалистами, хотя сам язык и экосистема содержат все, чтобы писать понятный, быстрый и поддерживаемый код и эффективно решать задачи.
мне кажется что без разницы, что писать сначала — код или тесты — главное чтоб выбранная методология повышала эффективность и стабильность конечного продукта
может я что-то не понял, но вот к примеру есть у меня gulp-задача, которая все скрипты/стили в 1 склеивает. Какой тогда смысл в этой библиотеке, если все что мне нужно будет окажется в нужном месте?
да, это и имеется в виду. я обычно для мелких домашних проектов, которые собираю из разных пакетов, использую https://github.com/auraphp/Aura.Di — простой, легкий и удобный, а еще не тянет кучу всего за собой
еще вопрос — а как экранируете вывод в шаблонах? например тут
с твигом по этому поводу париться бы не пришлось, да и вот такого тоже не было бы
Или же это применимо когда баг не в твоей зоне ответственности, но каким-то чудом знаешь где косяк
https://github.com/symfony/http-foundation/blob/master/Response.php#L422
или так
http://symfony.com/doc/current/components/http_kernel.html#component-http-kernel-kernel-terminate
подобное уже есть
Нужно менять скрипт или всю систему в таком случае
это и имеется в виду. Вдруг разработчик модуля слегка криворукий, а модуль все же полезный, мало ли что может быть. Пока работал с вордпрессом — такое бывало.
А так в gulpfile переписал путь и все, исходный файл не тронут
За советы спасибо, но я наверно не так объяснил что имел в виду — как раз визуальный редактор к примеру не нужен в публичной части сайта, а в админке норм
мне больше нравится подход чтоб я сам решал когда что подключить и нужно ли оно мне.
Вдруг я захочу вместо скрипта от модуля использовать свой?
Так я вместо скрипта от модуля напишу такс для своего и все, модуль продолжит обновляться, а мои изменения работать как мне нужно
Самый простой случай — разные модули зависят от чего-то одного — например, от загрузчика в админке, для которого свой кусок собирается, и на публичной части сайта — +1 строка в каждую секцию, не особо критично и просто
а если у вас такое в бекэнде модуля — то что-то у вас нечисто
такое разруливать самому, но случай какой-то странный.
это конечно круто, но я б отнес к разряду «свистелко-перделок».
Если нет ноды на серваке — то закидывать в cvs скомпилленные ассеты и не придется ничего запускать.
Даже если не используется никакая csv — по фтп закинуть скомпилленные файлы будет проще.
мы все еще про зависимости фронтэнда или про модули в вашей системе? Если модули в вашей системе — то что-то тут нечисто
удобнее, чем
в куче модулей.
Даже написание задачи gulp для нужных файлов все равно выйдет короче. Я б на вашем месте сделал gulpfile.js с заданием для скриптов/стилей модулей, которые у вас в комплекте идут, может кому понадобится
И как это совместимо будет с подходом
TypeScript->JavaScript, Less->CSS, SCSS->CSS?
гибко, читаемо, не костыльно.
В любом языке можно найти что-то кажущееся странным, например как тут
сам php вполне себе норм, но вот часть тех, кто на нем пишут — это ппц Х_х. Вроде бы на дворе 2016 год, а на работе в проектах от другой команды до сих пор видны ошибки вида «cannot modify header information — headers already sent» или же ошибки выполнения sql-запросов (вообще только за то, что это видит пользователь на странице, нужно отрывать руки с корнями)
Потому мне кажется, что всех кто связан с php можно разделить на 2 лагеря:
староверы — это те, кто работает с 1-2 cms, могут написать под них модуль, при работе с другими системами не могут переключиться на другой подход потому что привыкли, в основном делают сайты-визитки и шаблонные простые интернет-магазины клиентам. Про автоматизированное тестирование не слышали или же считают что проверить вручную будет быстрее. Таких лучше не подпускать к даже немного сложным проектам. Пишут в стиле php4 до сих пор, развитием языка и новыми фишками не интересуются. Код пишется в каком-нибудь notepad++. Деплой — закинуть файлы через фтп и залить дампы новых таблиц через phpmyadmin.
приверженцы современного подхода — эти люди чтят psr, работают с современными фреймворками, знают как работает веб-сервер и могут спокойно сами его настроить оптимально в зависимости от проекта. Вполне себе пишут еще на нескольких языках или хотя бы имеют представление о других подходах. Пишут тесты и знают какие они бывают. Стараются использовать последние фишки языка. Для работы используют IDE (phpstorm, netbeans и т.п.). Деплой чаще всего автоматизирован.
Разделение весьма условное, да и промежуточные варианты тоже существуют, но вот сам язык позволяет использовать оба таких подхода — и старый, потому что куча кода написанная ранее должна продолжать работать, и новый, т.к. язык развивается и новые проекты лучше начинать используя последние возможности. Получается, что к php наверно всегда будут относиться с некоторым пренебрежением и презрением из-за староверов и недоучек, которые после установки вордпресса мнят себя обалденными специалистами, хотя сам язык и экосистема содержат все, чтобы писать понятный, быстрый и поддерживаемый код и эффективно решать задачи.