Yii *

Доброго вечера, Хабрахабр.

Сегодня я расскажу о небольшом компоненте формы, который мне довелось написать для замечательного PHP фреймворка Yii. Этот компонент (а точнее, модель формы) позволяет редактировать config-файлы прямо из веба. Статья навеяна недавним постом о подобной функциональности, но та реализация основана на БД. Это не совсем нэйтивно для конфигурационных файлов Yii. К тому же за такое решение придётся заплатить лишними запросами к базе/кэшу, а их в проектах с высокой посещаемостью нужно экономить.

В статье будет много кода, но я постараюсь разделить его на логичные куски.

Привет.

Хочу поделиться небольшим модулем, предназначенным для создания страницы настроек в своём приложении. А заодно узнать у сообщества, что в нём можно было бы улучшить.

Задача по своей идее простая — сделать табличку в БД, хранящую параметры типа «ключ -> значение», а к ней сделать страничку редактирования, позволяющую изменять данные значения. ну и конечно же реализовать программный интерфейс для доступа к параметрам хранимым в БД.

Срок реализации — около получаса. В интернете почему-то готового решения было не найти. Исправим положение, авось кому пригодится.

После перерыва возобновил работу над модулем Yii, о котором писал чуть меньше года назад (пост).
Последние 2-3 недели в значительной мере были затрачены на написание/переписывание кода, и теперь можно вполне анонсировать версию 1.2.

Недавно передо мной встала задача, для решения которой удобно использовать PHP фреймворк. Изучив доступную информацию, описание, возможности,опрос на хабре (в котором, кстати, сумма опрошенных равна не 100%, а 143% (?)) был выбран Yii. Меня этот фреймворк устроил наличием необходимых фич, таких как авторизация и капча. На официальном сайте написано:

Yii — это высокоэффективный, основанный на компонентной структуре PHP-фреймворк для быстрой разработки крупных веб-приложений. Он позволяет максимально применить концепцию повторного использования кода и может существенно ускорить процесс веб-разработки.

Однако моё знакомство с Yii, которое началось с красивых формочек для генерации кода, быстро перешло к копанию в исходниках.

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

После RC и до стабильной версии (GA) будут приниматься исключительно багфиксы для RC.

Итак, выложен предварительный релиз Yii версии 1.1.13. Забрать, как обычно, можно со страницы загрузки фреймворка:

www.yiiframework.com/download/

Введение

Сегодня мы поговорим о блокировках и покажем свою реализацию. Каждый из разработчиков не раз сталкивался с проблемой, когда необходимо обеспечить однопоточное использование какого-либо ресурса.

Часто для обеспечения такой блокировки используется схема с созданием специального файла, наличие которого определяет факт занятости того или иного ресурса.

Такой подход достаточно прост в реализации, но имеет ряд недостатков. Среди недостатков можно выделить:

• отсутствие 100% гарантии блокировки при большом количестве потоков;
• блокировка работает в рамках одного сервера;
• и самое неприятное – если процесс, который поставил блокировку почему-то её не снял, то остальные процессы так и не смогут получить доступ к этому ресурсу, пока вручную или каким-то другим способом эта блокировка не будет снята.

Когда нужны блокировки?

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

В Yii для проверки актуальности кеша предусмотрены зависимости (Dependency). Они конечно позволяют многое, но, как всегда, не достаточно. Захотелось иметь возможность помечать кеш тегами так, чтобы при удалении любого тега, становился не актуальным весь кеш, помеченненый этим тегом.
Погуглив нашел пару статей по этому поводу:

• Кеширование в Yii с помощью тегов
• Тегирование кеша в Yii Framework — это не больно

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

В этой статье мы расскажем, каким образом мы организовали работу наших сайтов в одном проекте на фреймворке yii. В первой части приведем немного теории о том, в каких случаях такое может потребоваться и что для этого нужно. А во второй части приступим к технической реализации.

Часть 1

Введение

Многие компании поддерживают работу нескольких сайтов для продвижения своих товаров на разных рынках. Так делаем и мы. У нас есть сайты для русского, американского, европейского и других рынков, отдельные сайты для mobile-устройств, сайты партнерских программ, которые также различны для разных стран. В разработке мы используем фреймворк yii, на который мы в прошлом году перевели наш главный сайт Alawar.ru, а в этом году также Alawar.com, Alawar.pl и сайты iOS-устройств. Одна из особенностей деплоймента наших сайтов на yii заключается в том, что все они работают на одном инстансе этого замечательного фреймворка.

Проблемы в решении этой задачи нет, мы рассмотрим одну конкретную реализацию.

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

Данный пост будет интересен тем кто начинает знакомится с Yii framework, то есть пользователям от начального до среднего уровня знаний данного фреймворка, а так же тем кто любит похоливарить на тему какой из фреймворков круче.

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

Привет хабраюзеры!

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

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

Я хочу представить сообществу нашу реализацию RESTful архитектуры, без дублирования кода и с минимальными изменениями существующей бизнес-логики. Или Как добавить в проект API за пять минут?

Навеяно вот этой статьёй.

Хотел бы показать, как работаю с ресурсами я и почему нахожу такой подход дьявольски удобным.

Доброго времени суток.

На этот раз хочу, рассказать о способе автоматического подключения css и js файлов в Yii. Идея заключается в том, что бы к каждому файлу вида привязывать соответствующую папку с ресурсами (css, js, images). Это удобно, т.к. в большенстве случаев конкретные «assets» используются для конкретных файлов вида.

Как только я узнал об исполняемых PHP-архивах phar, сразу же захотелось их попробовать. Разработчиками, да и на хабре, это добро было довольно неплохо разрекламировано. Была информация о том, что использование архивов +APC даёт прирост производительности в 6 раз.

Привет всем любителям фреймворка Yii!

В цикле статей, хочу поделиться нашим подходом к разработке проектов на Yii. Возможно кому-то наши идеи будут полезны, возможно для кого-то это будет пища для размышлений, ну а возможно кому-то это нафиг не надо :). Я ни в коем случае не претендую на уникальность, не утверждаю, что делать надо именно так как это делаем мы.

Первый пост будет о конфигурации проекта, понимаю, тема избитая, ну куда ж без нее.

Команда PHP-фреймворка Yii выпустила новый релиз 1.1.12. Данный выпуск в основном исправляет проблемы, связанные с обратной совместимостью, которые были обнаружены после релиза 1.1.11. Было исправлено около 20 багов, добавлены не очень крупные фичи и сделаны мелкие улучшения.

15 человек поспособствовало выпуску данного релиза — мейнтейнеры и сообщество пользователей фреймворка благодарны им за внесённый вклад.

Всем привет!

Хочу поделиться с вами небольшим решением проблемы, с которой столкнулся при переносе части данных проекта в mongodb.
Изначально у нас использовалась только Mysql и все параметры приходящие от клиента вполне себе позволяли получать данные из базы без каких-либо проблем.

<?php
   $id = Yii::app()->request->getParam('id', 0);
   $data = Data::getForId($id);
?>

А суть в том, что для mysql нет разницы [select * from data where id = 1] или [select * from data where id = '1'].
Но mongodb типы данных различает, по этому нельзя найти запись используя условие id == '1' если id в mongodb является числом.

Команда PHP-фреймворка Yii зарелизила версию 1.1.11, в которую вошли более ста улучшений и багфиксов.

Этот релиз особенный потому как является первым с тех пор, как код Yii мигрировал на GitHub. Сообщество восприняло миграцию очень хорошо и выложилось по полной, прислав в виде pull-request новые возможности, исправления, unit-тесты и переводы.

За всё это огромное спасибо! Особенно отметим: resurtm, DaSourcerer, cebe и suralc.

Можно ознакомиться со списком изменений и новыми возможностями. Если планируете обновиться, внимательно читайте инструкции.

После релиза обнаружились некоторые неприятные ошибки. Работаем.

Ну а теперь рассмотрим некоторые изменения.