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.

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

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

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

Сейчас я расскажу про применение техники TDD для разработки моделей, используя Yii-framework.
Изначально предполагается, что была прочитана тема «Тестирование» из официального мануала (http://yiiframework.ru/doc/guide/ru/test.overview).

Итак, окружение настроено и сейчас нашей задачей будет — создать модели категории и продуктов(Category, Product) и покрыть их тестами.

Сделал я недавно некий тест, который выдал любопытные данные. Коими хочу поделиться, дабы помочь многим прояснит спорные ситуации.
Везде только и пишут, что насколько быстры массивы, насколько медлителен Active Record… Но когда видишь конкретные цифры гораздо легче понимать что на сколько лучше другого.

Используемые материалы:

— обычный ноутбук: Intel core 2 duo 2.13GHz, RAM 6 GB
— php 5.3
— apache 2.2
— framework Yii 1.1.10
— Active Record

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

Вместо предисловия
Занялся я с недавних пор Yii «по производственной необходимости». До этого сидел на ZF. Некоторые вещи в Yii кажутся неудобными или негибкими. В частности отсутствие раздельное конфигурации и работа с frontend/backend. Правда AR порадовал )). Но о чем это я?!

Ближе к делу
Начнем с самого начала, с удобной и гибкой конфигурации. Разумеется что перед решением по разделению конфигурации для паблик сервера и разработчика я полазил по форумам, посмотрел что пишут на хабре… Но все решения сводятся к определению имени хоста и решения на его основе о нужной конфигурации. Но увольте, есть же тестеры, есть команды разработчиков, есть много еще чего. В общем предлагаемый подход мне не нравится. Предлагаю свое решение по примеру ZF. Все очень просто. Я использую apache, поэтому решение для него. Весть секрет заключается в определении серверной переменной APPLICATION_ENV, а все остальное как везде.