• Изменения в Kohana 3.2 на русском

      Сегодня на хабре уже было сообщение о том, что вышел релиз Kohana 3.2. Я решил в меру свободного времени перевести информацию об изменениях, связанным с этим релизом. В описании собрана информация о самых, на мой взгляд, значимых изменениях.

      Читать дальше →
    • Зарелизилась Kohana 3.2.0

        image
        Поздравляю всех и каждого, сегодня зарелизилась новая версия фреймверка Kohana под номером 3.2.0.

        Изменений меньше, чем было при релизе 3.1.0, но и их хватает.

        С основным списком изменений и инструкции по обновлении можно ознакомится тут.

        Так же к новой версии был подготовлен и новый сайт, который можно наблюдать по адресу: kohanaframework.org
        Читать дальше →
      • Автоматическая сборка приложения на Kohana с применением Phar

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

          Начиная с PHP 5.2, появилась возможность распространять приложения или отдельные его компоненты в виде phar-архивов. Могу ошибаться, но пока такой подход не очень распространен. Я и сам никогда не пользовался таким способом дистрибуции ПО, но совсем недавно решил обратить на него внимание. В качестве эксперимента я выбрал один проект, который «крутится» на фреймворке Kohana. И вот, что у меня из этого вышло.
          Читать дальше →
        • Работа с OAuth v2

            Предлагаю почитать статью о «прикручивании» второй версии протокола OAuth (он на стадии черновика еще, ага). Сперва немного об общих принципах работы, потом привожу практическую часть (фреймворк Kohana, модуль OAuth).

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

            Дико извиняюсь, но топики-ссылки мне неподвластны. Вынужден нагло публиковать в качестве полноценного топика.
            • +20
            • 3,6k
            • 2
          • Первичный кэш в Kohana 3 с использованием тегов

            Приведенный пример является результатом решения одной задачи, которая возникла при разработке системы управления сайтом на фреймворке Kohana 3.1, в которой предполагается одна учетная запись администратора и множество незарегистрированных читателей.

            Требовалось надолго кэшировать результаты работы методов моделей, которые обращаются к базе данных. Фактически, требовалось создавать копии наборов данных из базы, чтобы снизить нагрузку на СУБД. Для немедленного обновления кэша при добавлении новых данных или обновления старых требовалась очистка кэша по тегам.

            Учитывая все это, и в связи с ограничениями используемых хостингов требования были следующие:
            • Кэш должен храниться в файлах.
            • Кэш должен храниться долго, для увеличения скорости извлечения данных и снижения нагрузки на СУБД.
            • При обновлении данных администратором сайта, кэш, содержащий устаревшие данные должен очищаться, причем, очищаться должен не только кэш результатов функций, напрямую извлекающих эти данные из базы, но и тех, результаты которых связаны с этими данными (например, при удалении рубрики каталога должен очищаться кэш списков позиций рубрик). Для достижения этой цели должны поддерживаться теги.
            • Ради достижения цели можно в определенных рамках пожертвовать временем, уходящим на добавление новых материалов, и которое будет затрачено в том числе на очистку кэша, так они добавляются «своим человеком», а не сторонними пользователями.

            Стандартный класс Cache_File не поддерживает теги, по этой причине потребовалось писать свой класс, ему было дано имя JetCache.

            Класс спроектирован по шаблону «одиночка». Рассмотрим пример работы класса в модели для банка файлов. При инициализации модели создается экземпляр:

            $this->cache = JetCache::instance();
            


            Создание кэша данных рассмотрим на примере функции для извлечения списка файлов определенной рубрики (здесь из нее удалены некоторые аргументы и некоторый код для упрощения чтения):
            Подробности далее
          • Видеокурс по Kohana 3.1

              Приветствую вас, уважаемые хабралюди!

              Хочу предложить вашему вниманию видеокурс моего производства по фреймворку Kohana 3.1.

              Что за видеокурс такой и кому он нужен: видеокурс бесплатный, доступен без предварительной регистрации — я не последователь Азамата Ушанова (да-да, такие еще остались, но нас очень мало).

              Основная цель видеокурса: рассказать понятным языком (доступным даже начинающему) о преимуществах ООП и MVC-подхода, о возможностях фреймворка Kohana в плане упрощения труда программиста в реализации часто используемых модулей.

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

              На кого рассчитан видеокурс: начинающие веб-мастера, желающие перейти от программирования на чистом PHP к MVC-фреймворку.
              Читать дальше →
            • Универсальная шаблонизация для Kohana 3.1

              Здравствуйте, уважаемые жители Хабра.

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

              Копаясь в таких монструозных штуках, как Drupal или Joomla, я понимал, что да, обилие развитого API и наличие большого количества модулей делает такие движки незаменимыми при создании сайтов практически любой сложности, однако, переходя на более простые вещи, вроде MVC фреймворков CodeIgniter или Kohana (последний, по существу, следует концепциям HMVC), приходило понимание, что колоть орехи ракетами земля-земля не всегда удобно, и легкость не только в обращении с кодом, но и в работе самого сайта, что называется, «решает».

              В настоящий момент я работаю на MVC (или HMVC, если быть точным) фреймворке Kohana, в частности, на ветках версий 3.0 и 3.1, и, попытавшись найти наиболее полное и элегантное решение для адекватной шаблонизации сайта, я с удивлением обнаружил, что либо мои навыки гугления морально устарели, либо действительно результаты подвели, но однозначно объективного лидера для моей задачи нет.

              Собрав некоторые из своих мыслей и наработок, я решил объединить их в удобную и интуитивную систему шаблонизации.
              Читать дальше →
            • Kohana 3.0 — упрощаем себе жизнь

                Фреймворк — это хорошо, это здорово, это возможность сэкономить кучу времени на раздумьях над архитектурой будущего приложения, но… Фреймворк как таковой — это каркас. И, на примере Kohana 3.0, о которой в данной статье пойдет речь, каркас этот надо, в той или иной степени, допиливать.
                Теперь давайте по-порядку, чем мы сейчас займемся:
                • -Расширим базовый контроллер, добавив в него жизненно необходимые методы и работу с юзерами (которая присутствует в 99% проектов, хотя бы на уровне административного логина)
                • -Создадим свой фронт-контроллер для более удобной и красивой работы с вью-файлами
                • -Реализуем вывод ошибок валидации через фронт-контроллер
                • -Улучшим базовый класс View
                • -Ну и еще кое-какие полезные мелочи

                Итак, начнем…
                Читать дальше →
              • Масштабирование веб-приложений с помощью HMVC

                • Перевод
                Последние десять лет мы наблюдаем второй цикл веб-дизайна – сайты превращаются в приложения и уже практически не появляется новых проектов, не обладающих некой долей интерактивности. Увеличение сложности ПО, разрабатываемого для интернета, вызвало необходимость в структурированном и взвешенном проектировании приложений.

                На сегодняшний день наиболее часто используемым паттерном проектирования сайтов является Модель-Вид-Контроллер (MVC). Повсеместное его использование отчасти вызвано успехом и популярностью фреймворка Ruby on Rails. Сейчас MVC является практически синонимом веб-разработки среди всех платформ.

                При выполнении задач, активно нагружающих процессор, современные сайты все больше полагаются на выделенные ресурсы. Этому, в частности, поспособствовало открытие компаниями Amazon и Google облачных сервисов, которые позволяют разработчикам существенно уменьшить нагрузку на процессоры их собственных серверов. Каждый сервис обычно проектируется в виде отдельного элемента ПО, который запускается внутри своего домена и использует свои собственные ресурсы.

                Когда имеешь дело со скромными бюджетами, обычно довольно сложно убедить клиентов в преимуществах финансирования более чем одного завершенного фрагмента программного обеспечения. Как показывает мой опыт, множество из них придерживаются мнения, что масштабируемость не является актуальной задачей. Они «с нетерпением ждут того дня, когда придется этим обеспокоиться».

                Для уменьшения первоначальных вложений обычно принимают решение о том, что приложение должно быть спроектировано в виде целостной программы, содержащей все требуемые функции. Если сайт быстро обретет популярность, это станет проблемой. У меня остались не очень приятные впечатления от рефакторинга плохо масштабируемых кодовых баз. К тому же, это может потребовать большого количества ресурсов и денег. В идеале приложения должны расти по мере необходимости и не требовать в процессе этого крупных финансовых затрат.
                Читать дальше →
              • Kohana 3: модуль “kohana-static-files”


                  При знакомстве с фреймворком, я первым делом смотрю не на его возможности, а на готовые решение, которые он предоставляет. В частности возможность удобно собирать JS/CSS файлы по частям и «отдавать» согласно рекомендациям по клиентской оптимизации (YSlow/Google PageSpeed). Ни в одном из просмотренных мной, нужной мне реализации я не увидел, даже в Django (которым, собственно, и был вдохновлен), поэтому решил сделать свое решение в виде готового к применению модуля для Kohana v.3.

                  Итак, опишем основные потребности/хотелки, которые ставились перед разработкой модуля:
                  1) Сборка inline CSS/JS по кусочкам
                  2) Возможность отдавать п.1 путем вставки в код страницы либо сгенерировав и записав на диск файл, с уникальным именем.
                  3) Возможность сборки внешних файлов CSS/JS в один билд
                  4) Возможность указывать условие, при котором подключается тот или иной билд из пункта 3, а также любой другой внешний файл (
                  <!--[if IE 7]>
                  ).
                  5) Возможность вынести статику на другой домен, главное чтобы он был на этом же физическом сервере.
                  6) Использование CDN
                  7) Минимизация CSS/JS.
                  8) Самое важное: СПОСОБ, позволяющий включать статику (а эо обычно не только CSS/JS, но и, например. картинки) в распространяемые модули. Так как текущий способ, когда в modules/ переносится и подключается сам функционал модуля, а статика либо копируется в произвольное место DOCUMENT_ROOT, либо обязательное условие – чтобы modules находилась в DOCUMENT_ROOT.
                  9) Возможность легко менять URL со статикой, чтобы он никак не конфликтовал с роутингом, например будет не хорошо, если вы захотите иметь раздел про CSS по урл ”/css/” когда до этого вы сделали это реально существующей директорией с файлами стилей.

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

                Самое читаемое