Comments 27
Как всегда, спасибо! PHP Virgin прикольные видео.
Любимый дайджест
Слон гулял с гофером :)
Ребята, а кто использует BDD в реальной жизни? Есть примеры?
Преимущественно BDD-тренеры :)
А из примеров, то можете взглянуть в этот проект — github.com/Sylius/Sylius
Разрабатывается по всем законам BDD
А из примеров, то можете взглянуть в этот проект — github.com/Sylius/Sylius
Разрабатывается по всем законам BDD
>> Реализация мультиязычности — Советы и рекомендации по реализации поддержки мультизычности в PHP-приложении.
Прямо-таки советы, как это НЕ надо делать
Прямо-таки советы, как это НЕ надо делать
Возможно, знаете другие источники, где были-бы советы как ПРАВИЛЬНО делать? Если да — поделитесь, пожалуйста.
По переводам моделей правильно сделано в Propel. На каждую переводимую таблицу создается своя таблица переводов. Тогда полный перевод любой строчки вытягивается одним простым джойном. То. что рекомендуется в статье (а именно так сделано в Doctrine) — образец гавноархитектуры. Если вам надо вытянуть 10 полей одной модели, надо делать либо 10 джойнов таблицы переводов, либо 10 отдельных запросов. Только поэтому мне в свое время пришлось сменить Doctrine на Propel.
По статическим переводам. Переводы должны храниться в БД, а не файлах. Потому что, когда заказчик попросит поменять запятую в одном слове, вы скажите «Вот вам админка, там сами можете свои переводы править».
По статическим переводам. Переводы должны храниться в БД, а не файлах. Потому что, когда заказчик попросит поменять запятую в одном слове, вы скажите «Вот вам админка, там сами можете свои переводы править».
Потому что, когда заказчик попросит поменять запятую в одном слове, вы скажите «Вот вам админка, там сами можете свои переводы править».
С такой логикой шаблоны тоже должны быть редактируемы из админки, а то вдруг заказчику захочется список на табличку поменять?
Переводы должны храниться в БД, а не файлах.
Категорическое нет. Для переводов (локализации) и интернационализации придумали миллион подходов. Самый простой для понимаия — локали и gettext, который ложится в память и практически не влияет на скорость генерации локализованной страницы.
Запомните одно простое правило — интерфейс != данные. Смешивать их даже на уровне системы хранения попросту чревато. Или у вас никогда не отваливалась БД? А так — показали холодные данные из кеша (пусть и немного прокисшие) даже при отсутствии живого соединения с базой, но в переведённом интерфейсе.
Хотя, для сайтишек на 3 калеки в час — сойдёт. Если больше — надо думать не столько о наполнении, сколько о живучести и задавать себе преинтереснейшие вопросы: а что будет если выключить CDN; а что будет, если завтра добавится новый backend; а сможет ли проект без переписывания масштабироваться горизонтально? И вот тогда наружу проступают эти изначальные архитектурные просчёты.
А то, что переводы из БД можно точно так же кэшировать хоть в каком кэше, вы видимо не додумались?
>> а что будет если выключить CDN; а что будет, если завтра добавится новый backend; а сможет ли проект без переписывания масштабироваться горизонтально
Причем тут это вообще не понятно. Любая система локализации никак не влияет на масштабирование.
>> Хотя, для сайтишек на 3 калеки в час — сойдёт
Ну так поясните нам, о каких нагрузках вы рассуждаете, а то знаете ли ORM и ООП — тоже могут быть «архитектурными просчетами».
Причем тут это вообще не понятно. Любая система локализации никак не влияет на масштабирование.
>> Хотя, для сайтишек на 3 калеки в час — сойдёт
Ну так поясните нам, о каких нагрузках вы рассуждаете, а то знаете ли ORM и ООП — тоже могут быть «архитектурными просчетами».
Причем тут это вообще не понятно. Любая система локализации никак не влияет на масштабирование.
Айяйяй. Я не уверен в этом. Даже джойн джойну рознь и может утопить СУБД. В данном случае — это попросту растрата ценного ресурса.
Ну так поясните нам, о каких нагрузках вы рассуждаете, а то знаете ли ORM и ООП — тоже могут быть «архитектурными просчетами».
Сколько экспрессии! Каков драматизм!
Ответ см. выше. Кроме абстракного 3+ посетителя — цифр приведено не было :) Как я смогу вам объяснить, что да. в некоторых условиях квадратные колёса поедут вполне комфортно, но для этого придётся готовить покрытие.
А зачем? Gettext их и так закеширует в памяти. Абсолютно прозрачно, без ещё одного слоя абстракции для кеша, без ещё одной внешней зависимости.
Я не адепт gettext, он просто пример. Я просто против совмещения интерфейса и данных. Все велосипеды придуманы и вам остаётся только складывать кирпичики в правильной последовательности. а не добывать глину, строить печь для обжига, выдерживать их и т.д.
Кстати, переводы надо не только хранить, но и поддерживать, дать удобный инструмент для переводчиков, задумываться о версионности, придумывать систему распространения переводов по узлам системы.
Отговорка: это не касается перевода данных (т.е. статей, постов, документации или любого другого контента)
Я не адепт gettext, он просто пример. Я просто против совмещения интерфейса и данных. Все велосипеды придуманы и вам остаётся только складывать кирпичики в правильной последовательности. а не добывать глину, строить печь для обжига, выдерживать их и т.д.
Кстати, переводы надо не только хранить, но и поддерживать, дать удобный инструмент для переводчиков, задумываться о версионности, придумывать систему распространения переводов по узлам системы.
Отговорка: это не касается перевода данных (т.е. статей, постов, документации или любого другого контента)
>> А зачем? Gettext их и так закеширует в памяти. Абсолютно прозрачно, без ещё одного слоя абстракции для кеша, без ещё одной внешней зависимости.
Кэш у вас есть в любом проекте, БД тоже. Вам не кажется, что этот ваш gettext как раз-таки и есть еще одна «внешняя зависимость»?
>> Кстати, переводы надо не только хранить, но и поддерживать, дать удобный инструмент для переводчиков, задумываться о версионности, придумывать систему распространения переводов по узлам системы.
А я о чем по-вашему говорю. Переводы надо в БД хранить именно потому что можно организовать нормальную систему правки переводов, хоть с версионностью, хоть с преферансом. Узнать, какие строки непереведены (вечный pain in ass при хранении в файлах) тут одним запросом.
Кэш у вас есть в любом проекте, БД тоже. Вам не кажется, что этот ваш gettext как раз-таки и есть еще одна «внешняя зависимость»?
>> Кстати, переводы надо не только хранить, но и поддерживать, дать удобный инструмент для переводчиков, задумываться о версионности, придумывать систему распространения переводов по узлам системы.
А я о чем по-вашему говорю. Переводы надо в БД хранить именно потому что можно организовать нормальную систему правки переводов, хоть с версионностью, хоть с преферансом. Узнать, какие строки непереведены (вечный pain in ass при хранении в файлах) тут одним запросом.
Все описанные проблемы по случайному стечению обстоятельств решены в gettext. Программа PO-edit. Она есть практически стандарт у переводчиков и не вызывает отторжения если я им даю английский файл (творческие люди, что с них взять :)). РО-edit прекрасно показывает непереведённые строки, строки с приблизительным переводом, умеет работать со множественными числами и т.д.
Распространение файлов переводов — задача системы доставки кода, которая наверняка уже есть в проекте.
Версионность — добро пожаловать в системы контроля версий. Новый коммит — новая версия. Тут всё просто.
Ngettext — множественные числа напрямую встроенные в модуль.
Моих переводчиков не пугали подстановки sprintf(), их спокойно можно использовать в тексте переводов.
На самом деле — мы ушли от темы. Не в gettext дело. Дело в том, что вы путаете данные (контент) и систему хранения контента (БД) с интерфейсом. Если какие- то менюшки, переводы, разметка хранятся в БД, чтож, пусть, но пусть это будет ДРУГАЯ БД. Подключенная в read-only в амазоне чтобы уменьшить время сборки страницы и при отказах не показывать пустой экран.
Засим дискуссию считаю законченной, спасибо за внимание.
Распространение файлов переводов — задача системы доставки кода, которая наверняка уже есть в проекте.
Версионность — добро пожаловать в системы контроля версий. Новый коммит — новая версия. Тут всё просто.
Ngettext — множественные числа напрямую встроенные в модуль.
Моих переводчиков не пугали подстановки sprintf(), их спокойно можно использовать в тексте переводов.
На самом деле — мы ушли от темы. Не в gettext дело. Дело в том, что вы путаете данные (контент) и систему хранения контента (БД) с интерфейсом. Если какие- то менюшки, переводы, разметка хранятся в БД, чтож, пусть, но пусть это будет ДРУГАЯ БД. Подключенная в read-only в амазоне чтобы уменьшить время сборки страницы и при отказах не показывать пустой экран.
Засим дискуссию считаю законченной, спасибо за внимание.
>> Программа PO-edit
Т.е. нам надо установить десктопную программу, чтобы управлять контентом сайта. Торжество идей web 3.0. Создатели Chrome OS плачут горькими слезами.
>> Если какие- то менюшки, ..., разметка хранятся в БД
Менюшки и разметку я не предлагал хранить в БД
>> Дело в том, что вы путаете данные (контент) и систему хранения контента (БД) с интерфейсом…
Каким образом вы так лихо определяете, где контент, а где интерфейс? В CMS шаблон — контент или интерфейс?
Тогда говоря вашей же терминологией, с того самого момента, как отдельный человек (переводчик) начинает сам заниматься редактированием переводов, то переводы становятся КОНТЕНТОМ, а не интерфейсом. Чем отличается переводчик от контент-менеджера? Вы контент-менеджеру для своих сайтов тоже предлагаете править данные в PHPMyAdmin? Нет, вы делаете нормальную админку с нормальным CRUDом. А почему переводчик (или заказчик) должен изучать какой-то POEdit или yaml или еще бог весть какие там форматы, в которых хранятся переводы?
>> Подключенная в read-only в амазоне чтобы уменьшить время сборки страницы и при отказах не показывать пустой экран
Я уже 2 раза писал и напишу в 3 раз, что мы кэшируем переводы и никакой разницы не будет.
Т.е. нам надо установить десктопную программу, чтобы управлять контентом сайта. Торжество идей web 3.0. Создатели Chrome OS плачут горькими слезами.
>> Если какие- то менюшки, ..., разметка хранятся в БД
Менюшки и разметку я не предлагал хранить в БД
>> Дело в том, что вы путаете данные (контент) и систему хранения контента (БД) с интерфейсом…
Каким образом вы так лихо определяете, где контент, а где интерфейс? В CMS шаблон — контент или интерфейс?
Тогда говоря вашей же терминологией, с того самого момента, как отдельный человек (переводчик) начинает сам заниматься редактированием переводов, то переводы становятся КОНТЕНТОМ, а не интерфейсом. Чем отличается переводчик от контент-менеджера? Вы контент-менеджеру для своих сайтов тоже предлагаете править данные в PHPMyAdmin? Нет, вы делаете нормальную админку с нормальным CRUDом. А почему переводчик (или заказчик) должен изучать какой-то POEdit или yaml или еще бог весть какие там форматы, в которых хранятся переводы?
>> Подключенная в read-only в амазоне чтобы уменьшить время сборки страницы и при отказах не показывать пустой экран
Я уже 2 раза писал и напишу в 3 раз, что мы кэшируем переводы и никакой разницы не будет.
Погуглил я этот gettext. Так и не понял в чем его фишка. Мало того, что надо устанавливать дополнительное расширение на php, так он еще геморный в управлении. Короче какой-то архаичный никому не нужный костыль, типа Pear. Вот, что, например, пишут здесь же на хабрахабре habrahabr.ru/post/108096/#comment_3419163. Заметьте, MySQL + memcached.
UFO just landed and posted this here
В сеть просочился исходный код популярного ресурса 4chan
extract($_POST);
extract($_GET);
extract($_COOKIE);
Это все объясняет.
А события моделей еще где-то есть? Вроде удобная штука
Секция DevConf::PHP расширилась
http://devconf.ru/offers/php
— Архитектура AVITO.ru
— Codeception — тестируем с человеческим лицом (автор Codeception)
— Асинхронный PHP — миф? Реальность!
http://devconf.ru/offers/php
— Архитектура AVITO.ru
— Codeception — тестируем с человеческим лицом (автор Codeception)
— Асинхронный PHP — миф? Реальность!
Мне показалось что Structr очень похож на symfony2/config дерево, кто то пользовался им? в чем преимущество?
Верю в существование дайджеста за 4 недели
Sign up to leave a comment.
Дайджест интересных новостей и материалов из мира PHP № 40 (14 апреля — 27 апреля 2014)