получите где-нибудь список доменных имен, которыми могут распорежаться только регистраторы (com.ru, co.uk и т.д.), отделите эту часть от строки, возьмите оставшуюся часть хостнэйма и уберите все до последнего элемента, приссоедините ранее убранное доменное имя верхнего уровня.
@Libris, ну я не думаю что это решит проблему с мобильными устройствами. Все эти штуки типа getComputedStyles и прочее очень дорогие операции, и на всяких андроидах это будет безбожно глючить.
Сходу по исходнику не нашел такой возможности, хотя можно ее добавить. Добавьте ишус автору, судя по всему он оперативно отвечает.
Такие вещи не нужно проверять в контроллере, просто валидировать перед обработкой каждого запроса (onBeforeRequest если мне память не изменяет), в итоге у вас всегда будет передана выбранная локаль. А скорее всего это умеет yii из коробки (если нет - то печалька).
А затем запрашиваете у какого-то сервиса/компонента такой-то контент для такой-то локали. А как это хранится у вас в базе - пусть об этом знает только этот сервис/компонент. Контроллерам не должно быть до этого дела.
не верстка а приложение на клиенте. LLVM так же не является бэкэндом, так как LLVM это совакупность инструментов скорее. Ладно там gcc является бэкэндом...
Еще у конвеера процессора есть фронт и бэкэнд, фронт поставляет микропрограмму, а бэк выполняет микрооперации. И много таких примеров.
@BBird, дефолтный валидатор не расчитан на такой вариант использования, так что вам придется реализовывать свой валидатор на основе стандартного, который так же проверят так же дубликаты на предмет совпадения по ID, например.
@Arris, вы не путаете функциональное с процедурным? ООП не ограничивает вас в применении парадигм функционального программирования. Более того, функциональное программирование не решает поставленных автором задач, но активно применяется внутри отдельных методов каких-либо классов.
По поводу "автоматизации разработки", вы перегибаете палку. С такими мыслями стоит отказаться от компиляторов и интерпритаторов, так как они автоматизируют и генерируют код за нас, когда мы пишем все на более приятных языках.
Да и потом, Бизнес-логику вам все-равно писать придется, а если при этом не придется писать кучу сервисного кода, то оно же хорошо. По поводу нового функционала, вы часто встречали проекты где требования и планирование нового функционала настолько далеко идут вперед, что можно за пол года предугадать развитие проекта? Я - нет. Частенько случается так, что требования к функционалу меняются уже вскоре после релиза очередной версии, что при сильной связанности системы превращается в очень трудозатратную задачу. С такими проектами проектировать систему с оглядкой на будущее становится просто нереально, и единственное что остается, проектировать систему так, что бы внесение изменений не вызывало много проблем. Это так же подразумевает юнит/интеграционное/функиональное тестирование что бы уменьшить количество регрессий и уменьшать задержки при доставке нового функционала.
Но никто конечно же не отменяет рационального мышления, программирование ради программирования тоже до добра не доводит. А "писать helloworld при помощи фабрик фабрик" попахивает нерациональным использованием инструментов.
С другой стороны, со всеми этими штуками аля PHP-DI, Composer, Symfony/HttpRequest, количество кода, позволяющее в кратчайшие сроки добавлять новый функционал, рефакторить не боясь регрессий, и в конечном итоге делать то, за что разработчику платят качественнее, снижают количество рутины при разработке и в конечном итоге и разработчик и клиент при грамотном подходе сохраняют больше нервных клеток за время разработки.
