PHPixie_logo

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

Как и например Symfony, PHPixie состоит из двух частей: библиотеки компонентов и базового проекта, правда в случае PHPixie базовый проект более тонкий и состоит всего из нескольких файлов. Он здесь исполняет роль примера и поэтому изменение его под себя не только приветствуется но в некоторых случаях даже необходимо. Именно для этого важно понимать что и как происходит в системе.

Конечно тем кто уже знаком с MVC  наверняка эта схема уже покажется знакомой, но для новичков может быть очень полезна. Итак начнем c index.php куда и попадают все запросы, здесь самые важные строчки это:

И сразу же мы попадаем на самую важную часть, класс App\Pixie который является сердцем фреймворка, его DI контейнером. Через него можно получить доступ ко всем другим компонентам. App\Pixie наследует от PHPixie\Pixie из библиотеки PHPixie-Core. Базовый проект оглашает этот класс вместо использования PHPixie\Pixie напрямую для предоставления разработчику возможности внести в него свои изменения ( например подключить модуль).

Сразу стоит отметить что добавлять новые сущности в этот контейнер на ходу, как например в Silex, нельзя, все надо описывать явно в классе. Хотя это и может показаться не таким удобным на первый взгляд, но зато позволяет добиться лучшей читабельности кода, полностью продокументировать все сущности (так как все они становятся атрибутами класса) а также получить подсказки по этим сущностям в IDE. Поскольку PHPixie\Pixie содержит также все фактори методы, то это позволят нам с легкостью заменить любой класс фреймворка на свой путем перегрузки соответствующего метода.

Метод bootstrap() инициализирует $pixie, считывает конфигурацию, подключает обработку исключений итд. Как раз в handle_http_request() проходит обработка запроса. Этот процесс состоит из трех этапов:

  • Создание объекта $request класса PHPixie\Request
  • Этот объект передается в соответствующий контроллер и выполняется соответствующий action
  • В процессе исполнения екшена контроллер изменяет объект $response ( PHPixie\Response )
  • Данные из $response (хедеры и контент) отсылаются пользователю

Все три самых важных объекта $request, $response и $pixie доступны как атрибуты класса PHPixie\Controller. Теперь отвлечемся немного на еще несколько парадигм написания кода на PHPixie:

Не использовать оператор «new» нигде кроме фактори методов. Каждый новый класс должен иметь фактори метод (например в App\Pixie) для создания его екземпляров. Такой подход позволяет легко заменить один класс другим, что особенно важно при написании юнит тестов. Так тестируя например контроллер вы теперь сможете передать в него замоканный App\Pixie который вместо реальных классов передаст их моки.

Не использовать статические проперти и методы. Использование статики сильно усложняет написание тестов. Используя PHPixie можно легко обойтись без них, достаточно добавить экземпляр как атрибут App\Pixie и вы сможете получить к нему доступ практически из любого места. Таким образом мы фактически получим синглтон. Кстати сделать это можно еще путем добавления его в $instance_classes.

Как работают модули

Каждый модуль для PHPixie это дополнительная библиотека классов которая предоставляет свой DI контейнер очень похожий на главный PHPixe\Pixie, то есть он состоит из методов фабрик для создания экземпляров классов который входят в модуль. Потом мы просто добавляем его в массив модулей в главный контейнер:

А что делать если я например хочу подменить класс PHPixie\ORM\Model на свой App\Model? Все просто, надо еще сделать свой App\ORM (extends PHPixie\ORM ) метод get() которого вместо модели PHPixie\ORM\Model будет возвращать ту что нужна нам. в этом еще больше проявляется одна из идей фреймворка — как можно больше использовать стандартные приемы ООП вместо каких-то магий. Например чтобы подменить класс самого фреймворка приходится применять subclass_prefix и делать єто на уровне конфигурации а не собственно программирования. Такой подход позволяет намного улучшыть понимание системы, так как по большей части в флове можно разобраться не зная ничего о фреймворке, просто посмотрев на сами классы.

А как же хуки, ивенты и прочее?

Их нет и я так понимаю не будет. Такие вещи полностью из другой парадигмы так как делают код нелинейным, особенно это относится к ивентам, где всегда не до конца понятно который из листенеров запустится первым и что случится если он сам вызовет какой-то ивент. А также от их использования очень часто страдает читабельность бектрейсов, так как они вызываются самим фреймворком где-то там где сам программист кода точно не писал. Если нужно что-то сделать в каком-то месте гораздо проще перегрузить метод который как-раз это и делает и дописать к нему ту логику что нужно.

nette-logo-oval

Работа с формами


Предусмотрена валидация как на стороне клиента (javascript), так и на стороне сервера. Присутствует встроенная защита от атак (XSS и CSRF). Несколько доступных режимов рендеринга формы. Интернационализация (i18n) позволяет создавать мультиязычные формы.

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

 

Собственный шаблонизатор


Latte. С хитрыми макросами, встроенными в HTML-теги. На вид, гораздо более читаемо, чем нативный PHP.

Важно, что шаблонизатор эскейпит переменные по умолчанию при выводе на страницу, что не позволяет забыть об этом. Упоминается некоторая умная технология Context-Aware Escaping, позволяющая автоматически корректно эскейпить различные переменные. Собственно, громких названий в этом фреймфорке хватает. Но, может, это не так и страшно.

Шаблонизатор должен быть быстрым, так как компилит шаблоны в чистый PHP код и сохраняет их в кэше.

В целом, шаблонизатор более простой и понятный, по сравнению с Smarty.

 

Конфиги


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

 

Кроме того


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

 

 

MNcVh0Z

Начало

Вторая версия отличается от первой кардинально. Список в краткой форме:

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

— Базовый CComponent разделили на Object и Component. Первый осуществляет работу геттеров и сеттеров, второй расширяя первый, добавляя события и поведения.

— Видоизменилось подключение событий и поведений. Подписываемся на событие

Настраиваем компонент

— Добавили новый класс View, теперь у нас настоящий MVC фреймворк. Представление

* View можно для каждого контроллера устанавливать, или использовать базовый для приложения.

— render() контроллера больше ничего не выводит. Оно возвращает данные

— В контроллере появились два события, на котрые можно подписываться: beforeAction, afterAction

— Убраны фильтры контроллера CFilter, теперь все делается через поведения

— В контроллере появился отличный помощник — метод populate

— Добавлены еще несколько статических классов-хелперов: ArrayHelper, StringHelper, SecurityHelper. Все хелперы теперь можно перекрыть через LSB. Ура, воскликнул я, т.к лично мне не раз нужно было перекрытьHtml.

— Виджет ActiveForm тоже переписан, и скорее всего заменит форм-билдер CForm. Каждое поле формы теперь может быть представлено как объект ActiveField, который создает ActiveForm

* Внимание: в Html::tag($tag, $content, $options) — изменили порядок параметров!

ActiveRecord

«По большей части, ActiveRecord осталась нетронутой»

— написано в предыдущей статье. Верно подмечено — не трогали.
Просто взяли и написали совсем другой ActiveRecord.

— Забываем про model()

— Убран CDbCriteria. Но не пугайтесь, работа с базой стала от этого легче. Появился ActiveQuery, который представляет себя гибрид CActiveFinder и CDbCriteria.

— Все общие методы теперь статические: getDb, tableName, find*, saveAll*, primaryKey. Выигрыш очевиден.

— Связи, куда же без них. Теперь связи определяются добавлением геттеров

— Для удобства работы со связями добавили link() и unlink(), который автоматически расставят ключи
— Именованные группы условий есть, но в другом виде. У нас же нет больше CDbCriteria, а значит и массивов условий тоже больше нет. Теперь это методы, причем статические, добавляющие условия в Query
  • Отсутствие обратной совместимости с Yii 1.1;
  • Пересмотрена архитектура классов, некоторые их реализации;
  • Отсутствие, как следствие новой архитектуры, некоторых сущностей, например: CDbCriteria, CClientScriptCUserIdentity и другие;
  • Поддержка шаблонизаторов Smarty и Twig.
Namespace
Псевдонимы путей
Компонент и объект
  • \yii\base\Object – легковесный класс, реализующий определение атрибутов класса через методы получение (set) и установки (get);
  • \yii\base\Component – является расширением вышеуказанного, который поддерживает дополнительно события (event) и поведения (behavior).
Консольные приложения

Yii 2.0 активно развивается

 

Что такое Symfony 2

symfony_logo-750x410

Высокопроизводительная среда (фреймворк) для разработки надёжных приложений на PHP5.

Symfony бесплатен и публикуется под лицензией MIT, не требующей дополнительных платежей. Проект активно спонсируется и развивается французской компанией Sensio.

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

Для чего Symfony 2 нужен разработчикам

  • Ускоряет разработку.
  • Оберегает от ошибок.
  • Стандартизирует разработку.
  • Облегчает доработку и поддержку.

Для чего Symfony 2 нужен заказчику

  • Гарантия профессионализма и высокого уровня разработки.
  • Независимость от одной компании.,

Версии

Цвет Описание
Красный Старая версия; не поддерживается
Зелёный Текущая версия
Голубой Планируемая версия
Версия Дата релиза Поддержка Версия PHP Версия ORM Окончание поддержки Заметки
1.0 Январь 2007 3 года >= 5.0 Январь 2010
1.1 Июнь 2008 1 год >= 5.1 Июнь 2009 Патчи безопасности выпускались до июня 2010
1.2 Декабрь 2008 1 год >= 5.2 Ноябрь 2009
1.3 Ноябрь 2009 1 год >= 5.2.4 Propel: 1.4Doctrine: 1.2 Ноябрь 2010
1.4 Ноябрь 2009 3 года >= 5.2.4 Propel: 1.4Doctrine: 1.2 Ноябрь 2012 Версия 1.4 идентична версии 1.3, но в ней не поддерживаются возможности, объявленные нежелательными к использованию в версии 1.3[6]
2.0[7] Июль 2011 >= 5.3.2 Doctrine: 2.1 Март 2013
2.1[8] Сентябрь 2012 8 месяцев >= 5.3.3 Doctrine: 2.2 Июнь 2013
2.2[9] Март 2013 8 месяцев >= 5.3.3 Doctrine: 2.2 Ноябрь 2013
2.3[10] Июнь 2013 3 года >= 5.3.3 Doctrine: 2.2.3 Май 2016 Первая версия в ветке 2.x с долгосрочной поддержкой
2.4[11] Ноябрь 2013 10 месяцев[12] >= 5.3.3 Doctrine: 2.2.3 Сентябрь 2014
2.5[13] Июнь 2014 8 месяцев >= 5.3.3 Doctrine: 2.2.3 Январь 2015
2.6[14] Ноябрь 2014 8 месяцев >= 5.3.3 Doctrine: 2.2.3 Июль 2015
2.7 Май 2015 3 года >=5.3.9 Doctrine: 2.2.4 Май 2018 Версия с долгосрочной поддержкой
2.8 Ноябрь 2015 3 года >=5.3.9 Doctrine: 2.2.4 Ноябрь 2018 Версия 2.8 вышла одновременно с версией 3.0 и является долгосрочной, но поддерживает возможности версии как 3.0 так 2.7. Версия 2.8 считается переходным на 3.0, она помогает перевести свой проект с 2.7 на 3.0. Версия 2.8 предупреждает о функциях которые не поддерживаются в 3.0 и помечает их как устаревшие, но дает возможность их все еще использовать.
3.0[15] Ноябрь 2015 8 месяцев >=5.5.9 Doctrine: 2.2.4 Июль 2016 Версия с поддержкой PHP 7.0
3.3 [15] Май 2017 3 года Версия с долгосрочной поддержкой

1. Установка и настройка

Скачать дистрибутив можно с официального сайта. Думаю лучше скачать версию-standart которая идёт со всеми дополнительными компонентами. Далее я предпологаю что архив был распакован в корневую папку вашего веб-сервера.
Проверить что все корректно работает можно по этой ссылке: http://localhost/Symfony/web/config.php.
Если все нормально, то можно начинать, но для начала нужно закомментировать одну строку в файле Symfony/web/app_dev.php

$kernel->loadClassCache();

Очень странное решение, по умолчанию включать кеш в режиме разработки.

2. Создание нового приложения

Приложения в Symfony 2 имеют модульную структуру, модули называются бандлами (bundle). Наше demo-приложение будет находиться в своём отдельно бандле. В Symfony существует очень много консольных команд, которые помогут вам в работе. Есть соответсвующая команда для генерации структуры нового бандла:

php app/console generate:bundle --namespace=Demos/BlogBundle

Эту команду нужно выполнить из консоли, находясь в папке Symfony/. Если вы работаете в линуксе, то можете присвоить файлу console права на выполнения и не писать перед ним php. Генератор задаст несколько простых вопросов на каждый из которых у него есть ответ по умолчанию. Так как мы создаём своё первое приложение, то согласимся на все варинты. Итак, нажав несколько раз клавишу enter мы получим скелет нашего бандла в папке Symfony/src/Demos/BlogBundle.

3. Контроллер и основы роутинга

Как и большинство современных фреймворков, Symfony придерживается паттерна MVC. Мы начнём своё знакомство с реализацией этого паттерна в Symfony с последней буквы, т.е. контроллера.
Наш маленький бандл уже имеет один контроллер, он называется DefaultController и находися в папке src/Demos/BlogBundle/Controller. Если вы заглянете внутрь него, то увидите что у него реализован экшен indexAction. Сейчас мы увидим что он делает. Откройте в своём браузере адресhttp://localhost/Symfony/web/app_dev.php/hello/username.
Вы можете удивиться почему именно такой адрес у этой страницы, но если внимательно посмотрите на PHPDoc (это такие специальные комментарии, которые начинаются с символов /**) перед функцией indexAction, то наверняка всё поймёте. Аннотация Route указывает по какому адресу доступен данный экшен и какой параметр он имеет.
Вообще, можно добиться того же и без аннотаций, но они применяются в Symfony повсеместно, так что лучше сразу к ним привыкать. С одной стороны они более лаконичны, а с другой для них не очень хорошо поддерживается автокомплит в моей любимой IDE.
За настройку того как будут выглядеть урлы вашего приложения отвечает специальный компонент Routing, он очень гибко позволяет всё настроить. Более подробно можно почитать в соответсвующем разделе документации. Мы же кратко рассмотрим почему наше приложение открывается именно по этому адресу и почему от нас не потребовалось для этого ничего настраивать.
Если вы не очень внимательно читали что у вас спрашивал генератор бандла, то вполне могли пропустить его вопрос о том обновить ли настройки роутинга в соответствии с новым бандлом. Если пропустили, то можете открыть файл Symfony\app\config\routing.yml. Там вы увидите такую запись:

DemosBlogBundle:
resource: "@DemosBlogBundle/Controller/"
type: annotation
prefix: /

Первая строка — это название секции с конфигурацией, оно соответсвует имени нашего бандла. Вторая строка — указывает откуда импортировать настройки. В данном случае будут читать все файлы из папки с контроллерами, а следующая строка говорит что все необходимые настройки описаны в аннотациях экшенов. Ну а аннотации мы уже видели. И, наконец, последняя строка указывает какой префикс будет добавлен ко всем урлам из нашего бандла. По умолчанию все урлы доступны напрямую от имени входного скрипта. Давайте поменяем / на /blog чтобы было более логично.
Теперь все что мы будем делать будет доступно по адресу http://localhost/Symfony/web/app_dev.php/blog.

4. Работа с Doctrine: создание модели

Теперь перейдем к следующему шагу — работе с базой данных. Я буду использовать Doctrine, хотя никто не обязывает этого делать, вместо доктрины можете использовать любой удобный вам способ работы с бд. Однако, доктрина хорошо интегрирована с symfony и работать с ней одно удовольствие.
Для начала настроим подключеник к бд. Откройте файл app/config/parameters.ini и опишите свои настройки. Кстати, интересно, почему все настройки по дефолту в yml, а этот в ini-файле. Если в настройках вы указали не сущесвующую базу данных, то выполните следующую команду:
php app/console doctrine:database:create
и доктрина сама создаст её.
Доктрина является полноценной ORM, но построна она по другому принципу нежели ActiveRecord, с которым у многих сейчас однозначно ассоциируется это понятие. Доктрина реализует шаблон Data Mapper который очень подрбно описан здесь.
Для начала нам нужно описать сущность с которой мы будем работать. Это будет класс Post с нужными нам свойствами. Создайте папку src/Demos/BlogBundle/Entity. В ней создайте файл Post.php и заполните его следующеим кодом:

<?php
namespace Demos\BlogBundle\Entity;

use Doctrine\ORM\Mapping as ORM;

/**
* @ORM\Entity
* @ORM\Table(name=”post”)
*/
class Post {

/**
* @ORM\Id
* @ORM\Column(type=”integer”)
* @ORM\GeneratedValue(strategy=”AUTO”)
*/
protected $id;

/**
* @ORM\Column(type=”string”, length=255)
*/
protected $title;

/**
* @ORM\Column(type=”text”)
*/
protected $body;

/**
* @ORM\Column(type=”datetime”)
*/
protected $created_date;

/**
* @ORM\Column(type=”datetime”)
*/
protected $updated_date;
}

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

php app/console doctrine:generate:entities Demos/BlogBundle/Entity/Post

Теперь посмотрите в файл Post.php, в нём должны были появиться соответсвующие методы. У нас есть есть описание модели, по ней нужно создать соотвествующую таблицу в базе данных. Для этого выполните:

php app/console doctrine:schema:update --force

Если все прошло без ошибок, то в вашей бд должна было появиться таблица post. Перейдём к непосредсвенной работе с объектами. В классе DefaultController создайте новый экшен с таким кодом:

/**
* @Route("/create")
*/
public function createAction() {
$post = new Post();
$post->setTitle('Demo Blog');
$post->setBody('Hello Symfony 2');
$post->setCreatedDate(new \DateTime("now"));
$post->setUpdatedDate(new \DateTime('now'));

$em = $this->getDoctrine()->getEntityManager();
$em->persist($post);
$em->flush();

return new Response(‘Created product id ‘ . $post->getId());
}

А в начало файла нужно добавить импорт нужных пространств имён:

use Demos\BlogBundle\Entity\Post;
use Symfony\Component\HttpFoundation\Response;

Теперь если вы откроете адрес http://localhost/Symfony/web/app_dev.php/blog/create, то в ответ должны получить id созданной записи.
Теперь создадим экшен для вывода сущесвующих записей. Для этого нам понадобится экшен с параметром, который будет принимать id записи.

<?php
/**
* @Route("/show/{id}")
*/
public function showAction($id)
{
$post = $this->getDoctrine()->getRepository('DemosBlogBundle:Post')->find($id);

if (!$post) {
throw $this->createNotFoundException(‘Страница не найдена!’);
}

$html = <<<HTML
<h1>{$post->getTitle()}</h1>

<p>{$post->getBody()}</p>

<hr/>
<small>Запись создана {$post->getCreatedDate()->format(“Y-m-d H:i:s”)}</small>
HTML;

return new Response($html);
}
?>

Теперь можете просмотреть запись пройдя по ссылке http://localhost/Symfony/web/app_dev.php/blog/show/1. На этом с доктриной закончим, подробности в документации.

5. Twig: первые шаблоны

Пора перейти к заключительной части нашего знакомства с Symfony. На прошлом шаге мы поступили не очень хорошо смешав логику работы с выводом записи в showAction. Избавиться от этого недостатка нам поможет View (по русски «вид» звучит как-то не очень хорошо, поэтому я буду называть это вьюхой ;).
В качестве шаблонизатора Symfony использует Twig — пожалуй лучший PHP-шаблонизатор с которым я работал. Как и любой другой компонент симфони можете заменить его на то, что вам больше нравится.
Как вы помните у экшена indexAction есть специальная аннотация Template(), которая говорит что у него есть шаблон.

return array('name' => $name);

Массив который возвращается из экшена передаётся во вьюху, ключи массива буду именами переменных которые будут там доступны.
Давайте изменим экшен show. Нужно добавить соответсвующую аннотацию и вместо того чтобы возвращать объект Response вернуть массив в котором будет просматриваемая запись. Вот что получилось:

/**
* @Route("/show/{id}")
* @Template()
*/
public function showAction($id)
{
$post = $this->getDoctrine()->getRepository('DemosBlogBundle:Post')->find($id);

if (!$post) {
throw $this->createNotFoundException(‘Страница не найдена!’);
}

return array(‘post’ => $post);
}

Согласитесь, так гораздо лучше. Теперь в папке src/Demos/BlogBundle/Resources/views/Default создайте файл show.html.twig в который перенесите html код который был у нас экшене. Синтаксис твига отличается от php поэтому придется кое-что изменить. Конечный вариант смотрите в исходниках. Узнать больше о синтаксисе твига можно в его документации.

 

CodeIgniter: Обзор фреймворка для PHP

 codeigniter_logo

Для разработки современных WEB-приложений «голого» языка программирования уже давно недостаточно. Если вы привыкли разрабатывать проекты на php, то вам хороша, известна ситуация, когда приходится писать/переносить кучу повторяющегося рутинного кода для очередного проекта. Из этого положения каждый девелопер выкручиваться по-своему – одни создают свои шаблоны и используют их повсеместно, другие – выбирают всевозможные надстройки для языка – CMF (Content Management Framework).

Почему нужно использоваться фреймворки?

Переходить к использованию фреймворков заставляет не дань моде, скорее это неизбежный шаг, который рано или поздно вынужден совершить любой WEB-программист. Приложения «из браузера» каждый день усложняются, и по функционалу уже давно не уступают многим десктопным вариантам. Разобраться со всеми современными технологиями, используемыми для разработки таких сложных приложений достаточно трудно, а иногда и вовсе невозможно, поскольку появляются они крайне динамично. Чтобы всегда оставаться на коне приходится выбирать CMF, которые упрощают процесс адаптации к новым технологиям. Но не будем петь хвалебных песен CMF, а сразу назовем пять причин, по которым стоит распрощаться со стереотипами и начать использовать фреймворки в своих проектах:

1. Постоянная структура. При использовании фреймворков требуется четкое разделение ролей для каждого файла проекта. Например, если фреймворк построен на архитектуре MVC, то все созданные вами контроллеры, представления и модели будут лежать по разным папкам. При постоянной разработке новых, а также поддержки старых проектов не нужно ломать голову над вопросом: «А куда же я положил такой то сценарий?» или «Где у меня реализована такая-то функция». Кроме того, дальнейшую поддержку таких проектов гораздо проще передавать другим программистам. Ведь чтобы они смогли разобраться в коде и принципах его построения, им достаточно взглянуть на документацию фреймворка.

2. Никаких велосипедов. Пожалуй, каждый программист хоть раз да умудрялся изобрести свой велосипед. Причин может быть много, но самая распространенная – невозможность найти готовое решение. При использовании фреймворков все намного проще, т.к. почти все CMF несут на своем борту кучу библиотек/плагинов с готовым кодом и еще кучу всевозможных полезностей валяются на просторах интернета.

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

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

5. Оперативная помощь. Получить квалифицированную помощь при использовании фреймворка просто и быстро. Любой популярный и функциональный CMF имеет сообщества, постоянно занимающиеся тестированием и поддержкой.

Разрешите представить – Code Igniter

За свою практику разработки приложений для WEB мне пришлось перепробовать несколько фреймворков. Некоторые из протестированных мной CMF были чересчур сложны в использовании и изучении (например, фреймворк от Zend) – разработка приложений с помощью таких продуктов не упрощалась, а усложнялась. Усложнения мне были не нужны, поэтому я продолжал искать альтернативу. К счастью она нашлась, – ей стал Code Igniter.


Рисунок 1 (Официальный сайт CodeIgniter)

Возможности CodeIgniter

Code Igniter – бесплатный функциональный фреймворк для php программистов. Среди ключевых возможностей этого продукта можно выделить:

1. Полная совместимость с php 4. Хоть сейчас это не столь актуально, но пару лет назад, когда у большинства хостеров была установлена четвертая версия этого интерпретатора, Code Igniter выгодно отличался на фоне конкурентов. Так, что если вы до сих пор застряли во вчерашнем дне или использоваться php4 вас обязывают другие причины, то теперь вы сможете это делать вместе с Code Igniter.

2. Простой в изучении. Сравнивая Code Igniter с альтернативными решениями можно смело сказать, что он наиболее прост. Помимо хорошо продуманной архитектуры проекта, разработчики не схалтурили и снабдили свое детище отличной документацией. Действительно, документация у CI написана подробно, хорошо структурирована и оперативно обновляется.

3. Безопасность. Проблемы в системе безопасности присущи всем WEB-проектам, однако с CI многие из них решаются автоматически. Например, для точной фильтрации полученных данных на предмет XSS есть встроенная функция, которая позволяет не только удалить, но и сохранить в лог опасные данныеь. Очень удобно.

4. Расширяемость. CI очень гибок и хорошо поддается расширению. Научить фреймворк новым возможностям – пара пустяков. Достаточно подключить нужный плагин/хелпер/библиотеку и начать радоваться новому функционалу. 5. Богатые возможности. Вместе с CI поставляются библиотеки, плагины, хелперы, которые позволяют сразу перейти к решению задач и не заморачиваться изобретением велосипедов. Не нужно заниматься кодокопанием, достаточно воспользоваться специальным механизмом, позволяющим без танцев с бубном «перевоспитать» CI.

6. Active Record. В CI используется модифицированная версия паттерна Active Record Database. С помощью Active Record, работа с базой данных превращается в сплошное удовольствие. Больше не придется писать многочисленные «SELECT» для выбора данных, достаточно лишь воспользоваться методами этого класса, а это всего две небольшие строчки кода. Помимо упрощенного доступа к БД, этот класс позволяет забыть об используемой СУБД. Вы можете построить приложение, используя MySQL, а потом также легко запустить его под Oracle. И это еще не все. Ко всему прочему, AR позволяет хоть немного, но обезопасить работу с СУБД, т.к. при составлении запросов все значения экранируются.

7. Высокая производительность. Столь большие возможности ничуть не повлияли на производительность фреймворка. Работает он действительно шустро. Такое быстродействие достигается за счет очень «легкого» ядра. Все дополнительные библиотеки подключаются лишь по мере необходимости.

8. Архитектура MVC. CI заточен под архитектуру MVC (Model-View-Controller), позволяющую отделить логику от отображения. При работе в команде (программисты + дизайнеры), такой подход будет весьма востребован.

9. Поддержка шаблонизатора. Несмотря, на то, что CI не требует обязательного использования шаблонизатора, при желании им можно воспользоваться.

10. Дружественность к поисковикам. Благодаря своим URL’ам, Code Igniter отлично дружит с поисковыми система и поддается индексации.

MVC

Model View Controller (MVC) – архитектура программного обеспечения, позволяющая разделить модель данных, пользовательский интерфейс и управляющую логику на три отдельные составляющее. Причем разделить ее так, что изменение одного не повлияет на работу других компонентов. Использовать эту архитектуру очень удобно при разработке больших проектов, работа над которыми идете в команде. Например, работая над проектом, программистам не нужно заботиться о будущем интерфейсе. Их цель – получить и обработать данные, а потом отправить их пользователю. Вид, в котором пользователь получит эти данные, программистов волновать не должен. Это уже работа дизайнеров и верстальщиков, которые могут параллельно создавать представления для полученных данных. Что же касается программистов, то они тоже могут распараллеливать свою работу – например, часть разработчиков может сосредоточиться на разработке логике программы, а другая – на проектировании структуры базы данных. Как видно из примеров, при использовании MVC становится возможным распараллелить работу команды, тем самым повысить общую производительность. Итак, MVC состоит из сущностей:

1. Model (модель) – служит для предоставления данных. Как правило, в модели описываются функции, классы для работы с базой данных.

2. View (представление) – отвечает за передачу пользователю обработанных данных.

3. Controller (Контроллер) – занимается интерпретацией запрашиваемых/отправленных пользователем данных, взаимодействует с моделью для их получения. Важно заменить, что Code Igniter, в отличие от других MVC-фреймворков не заставляет использовать MVC в полной мере. Если вам не удобно делить код на три составляющие, то это делать вовсе необязательно. Для создания рабочего приложения вы можете ограничиться одним лишь контроллером, организовав в нем все логику и работу с СУБД. Тем немее, понимание MVC, позволит вам в будущем с легкостью осваивать альтернативные фреймворки (список их можно увидеть в соответствующей врезке).

Установка Code Igniter

Свежий дистрибутив фреймворка вы всегда можете взять с www.codeigniter.com. Разработчики достаточно часто обновляют свой продукт, поэтому я советую подписаться на RSS и постоянно быть в курсе всех последних изменений. Итак, предположим, что вы скачали дистрибутив фреймворка. Теперь можно распаковать архив в папку DocumentRoot web-сервера Apache. Вследствие этих нехитрых действий фрейморк становится готов к работе, в чем легко можно убедиться, зайдя на ваш сайт. Если фреймворк работает успешно, то в браузере появится картинка примерно такая, как на рисунке 2.


Рисунок 2 (Фреймворк готов!)

Базовая настройка

Пока работоспособность фреймворка не представляет ничего интересного (такое окно и средствами php недолго вывести), поэтому двинемся дальше и посмотрим на структуру каталогов, которая у нас получилась после распаковки файлов дистрибутива. В корне папке Document Root у нас появилось два каталога и один файл (index.php). Откроем этот файл в php редакторе. Настройки этого файла влияют на работу всего проекта, созданного на основе CI.

Итак, давайте посмотрим на наиболее важные переменные, доступные для изменения в этом файле. $sytem_folder – название и путь к папке, содержащей все внутренности CI. $aplication_folder – путь к папке с приложением. Значение этих переменных можно оставить по умолчанию, но при использовании CI в реальных проектах я вам рекомендую переименовать эти папки и изменить путь. Это необходимо делать в целях безопасности. Незачем никому знать в какой папке вы храните файлы вашего приложения. По своему опыту работы с этим фреймворком, я рекомендую создать отдельную папку, в которой вам предстоит хранить все свои проекты. Например: project/application1, prroject/application2.

Таким образом, вы сможете на одной копии фреймворка создавать и поддерживать несколько отдельных проектов. Помимо изменений путей к папкам, в файле index.php вы также можете изменить вид отображения ошибок (error_reporting()). По умолчанию будут отображаться все ошибки, но опять же, в реальном приложении лучше ничего не отображать. Теперь перейдем в папку приложения – system/application. В ней содержится несколько каталогов:

/config – здесь хранятся все настройки для текущего проекта.

/controllers – в эту папку нужно сохранять все созданные вами контроллеры.

/error – шаблоны для страниц-ошибок.

/helpers – папка предназначена для хранения созданных вами хелперов.

/hooks – директория для «ловушек».

/language – папка для хранения языковых файлов.

/libraries – все созданные вами библиотеки должны быть здесь.

/models – папка с моделями данных.

/views – директория для хранения представлений вашего проекта.
Изучая дерево директорий проекта Code Igniter, вы наверняка обратили внимание на незнакомые названия. Чтобы не путаться и говорить друг с другом на одном языке, давайте дадим им определения. Итак, в платформе CI, существуют следующие сущности:

Helpers (Хелперы) – коллекции функций. В каждом вашем проекте может возникнуть необходимость объявить что-нибудь специфическое. Вот все эти функции лучше всего объявлять в хелперах. Для удобства использования, хелперы обычно группируют по входящим в них функциям. Например, файловый хелпер, в него входят функции для работы с файлами.

Hooks (Ловушки) – встроенная в CI технология, позволяющая изменить поведения работы фреймворка без внесения изменений в ядро. Libraries (Библиотеки) – ваши собственные классы. Все свои классы, выполняющее универсальный код, в CI принято определять как библиотеки.

Практика

Чтобы продемонстрировать реальные возможности Code Igniter, я решил на практике рассмотреть процесс создания такого популярного сервиса как «Блог». Сегодня вести блоги чрезвычайно модно, поэтому пример весьма актуален. Итак, приступим. Первым делом подготовьте фреймворк к работе – распакуйте его дистрибутив в папку DocumentRoot WEB-сервера Apache.

Откройте файл /system/application/config/config.php, найдите в нем определение base_url (базовый урл) и укажите полный путь к папке, в которой расположен CI. Если вы распаковали его в корень директории DocumentRoot и будете разрабатывать проект на локальной машине, то просто укажите здесь: http://127.0.0.1. Все, больше нам config.php не понадобится и потому его можно закрывать. Теперь нам нужно определить контроллер, который будет загружаться по умолчанию (т.е. когда пользователи будут обращаться к http://127.0.0.1).

Несмотря на то, что мы еще ничего и не создали, но скоро точно создадим, а создадим мы контроллер с именем Blog, поэтому давайте сразу пропишем к его в маршрут по умолчанию. Все маршруты описываются в файле routes.php, который расположен в папке config. Открываем этот файл, находим $route[‘default_controller’] и присваиваем ему значение Blog. Сохраняем. При разработке нашего первого проекта, нам потребуется возможность обращаться к разным хелперам. Поэтому нам необходимо указать, чтобы эти хелперы запускались автоматически (хотя их инициализацию можно производить прямо в коде). Чтобы определить объекты, которые должны инициализироваться при старте, нужно отредактировать еще один файл настроек – autoload.php. Откроем этот файл и найдем секцию, в которой происходит описание автозагрузки хелперов (Auto-load Helper Files). Следуя шаблону из комментария, опишеме следующие хелперы: html, url, typography.

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


Рисунок 3 (Разработка в самом разгаре)

Создаем базу данных

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

1. tblcomments – комментарии, оставленные пользователями:

2. tblrecords – таблица будет содержать все записи блога:


Рисунок 4 (Макет базы данных)

Готовим модель

Итак, создадим новый файл для будущей модели, перепишем в него код из первого листинга, сохраните в файл mblog.php:

Листинг 1. Модель

Описание любой модели в CodeIgniter начинается с определения нового класса-наследника от Model. Самое первое, что я делаю после объявления класса – вызываю конструктор. Обратите внимание, что для определения конструктора я использую функцию с именем таким же как и у класса. Этот метод используется в php4, а для php5 мы должны использовать __contruct(). По идее, для этой модели нам не нужно использовать конструктор, его объявление я привел только для демонстрации. Когда в реальном приложении вам потребуется описать конструктор, то не забудьте в самом начале указать parent::Model. Это необходимо делать для того, чтобы, конструктор вашего класса не перекрывал конструктор класса Model.Итак, давайте взглянем на функцию с именем get_last_record();. В первой строчке тела этой функции я обращаюсь к классу db и вызываю функцию order_by(). Эта функция позволяет установить оператор ORDER BY для будущего запроса. В качестве параметров, функции нужно передать:

– поле, по которому нужно упорядочить данные – направление упорядочивания. В блогах принято, чтобы новые записи были в самом верху, поэтому в качестве имени поля я передаю «date», хранящий дату публикуемого топика, а во втором параметре указываю desc (по убыванию). Установив Order by, можно смело выполнять запрос. Для простого получения данных в AR есть метод get(), который принимает два параметра:
– имя таблицы, из которой выбирать данные
– количество записей для выборки

Думаю, с выборкой данных все понятно и вы уже смогли прочувствовать прелести использования ActiveRecords, теперь давайте взглянем на то, как делается добавление новых записей в таблицу. А делается она очень просто. Для вставки используется метод insert() класса db. Методу нужно передать всего лишь два параметра:

– имя таблицы
– массив данных, в котором ключ – это имя поля в таблице

Делаем контроллер

Мы создали модель, теперь нам предстоит создать контроллер, который сможет плодотворно с ней работать. Создайте новый файл и перепишите в него код из листинга 2. Хочу сразу предупредить, что во втором листинге приведен лишь отрывок кода, полный исходный текст вы можете получить по ссылке в конце статьи.

Листинг 2. Контроллер.

Первое, с чего начинается новый контроллер – с описания нового класса-наследника от Controller. Для нашего примера я объявил класс Blog. В самом классе, нам нужно описывать функции, имена которых будут с url’ами. Например, объявив функцию foo(), и обратившись по адресу http://localhost/index.php/blog/foo мы спровоцируем ее выполнение. Но вернемся к нашему листингу. Сразу после описания класса, у меня идет объявление функции index(). Функция с таким именем будет автоматически вызывать при обращении к нашему контроллеру (http://localhost/index.php/blog).

В теле этой функции, я в первую очередь инициализирую созданную нами модель. Для инициализации используется loader load -> model. В качестве параметров я передаю ему имя созданной нами модели и также значение true, указывающее на то, что установка с БД должна произвестись автоматически. После инициализации модели я сразу обращаюсь к одной из ее функций – get_last_record().

Как вы помните, после выполнения, эта функция возвратит все имеющиеся в ней записи. Полученные данные нужно отправить пользователю, для этого я загружаю представление vblog. Для загрузки представлений используется конструкция load -> view(). Из параметров нужно передать:

– Имя представления
– Данные, из которых будет формироваться страница для пользователя.

Пример исходного текста представления вы можете посмотреть в листинге 3. Я не буду подробно расписывать содержимое листинга, поскольку все, что в нем происходит – печать данных стандартными средствами php. Единственное, что нуждается в объяснении – получение имен переменных. Как ты помнишь, при вызове представления, в качестве третьего параметра мы передавали массив с данными. Получение значений осуществляется через переменные, имена которых равны именам ключей передаваемого массива. Например, если у нас есть массив array с ключом sample ($array[‘sample’]), то для того, чтобы получить доступ из представления к значению sample, нам нужно из представления всего лишь на всего обратиться к переменной $sample.

Листинг 3. Первое представление

Тестируем пример

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


Рисунок 5 (Блог в действии)

Некрасивые url

Посмотрев наш «блог» вы наверняка заметили в адресной строке url вроде http://localhost/index.php/blog. Такой url выглядит ужасно и совершенно не годится для реального проекта. Для улучшения внешнего вида url, я рекомендую вам воспользоваться возможностями плагина mod_rewriter WEB-сервера Apache. С его помощью вы быстро приведете url к должному виду.

Заключение

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

LARAVELLaravel — бесплатный веб-фреймворк с открытым кодом, предназначенный для разработки с использованием архитектурной модели MVC (англ. Model View Controller — модель-представление-контроллер). Laravel выпущен под лицензией MIT. Исходный код проекта размещается на GitHub

В результате опроса sitepoint.com в декабре 2013 года о самых популярных PHP-фреймворках Laravel занял место самого многообещающего проекта на 2014 год

В 2015 году в результате опроса sitepoint.com по использованию PHP-фреймворков среди программистов занял первое место в номинациях:

  • Фреймворк корпоративного уровня
  • Фреймворк для личных проектов

Laravel — это чистая и стильная основа для разработки. Он избавит вас от спагетти кода. Поможет вам создавать прекрасные веб-приложения используя простой и выразительный синтаксис. Разработка должна доставлять удовольствие. Наслаждайтесь глотком свежего воздуха.

Еще один PHP фреймворк, подумаете вы. Возможно, но он стоит того, чтобы на него посмотреть.
Фреймворк довольно молодой, 2011 год. Использует PHP 5.3. У него уже хорошее сообщество, много форков. Уже дорос до версии 3.0.

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

Что умеет

Bundles ( Модули ) — имеется репозиторий с обширным количеством бандлов.

The Eloquent ORM — ActiveRecordORM, умеет строить связи ( many to many, one to many, one to one )

Migrations — думаю, правило хорошего тона.

Redis — да, noSQL из коробки.

Environments — в зависимости от домена, может подгружать те или иные конфигурационные файлы.
Скажем, пропишем в файле paths.php

Теперь, если мы зайдем с домена начинающегося на localhost или заканчивающегося на .dev. Фреймворк будет подгружать файлы конфигов с папк application/config/local/* вместо application/config/*

IoC Container — методы для создания и, опционально, инстанцирования и хранения ссылок синглтонов. Это также значит, что вы будете меньше нуждаться в подгрузке внешних библиотек.

Class Auto Loading — так же, можно переопределить в конфиге любой системный класс.

Работа из под CLI — устанавливайте\создавайте миграции, бандлы, запускайте нужные роуты (крон скажем).

Имеется asset менеджер. Весь код вынесен за пределы публичной директории.

Возможностей из коробки довольно много, кому интересно, тот заглянет глубже.

 

 

opencart1

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

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

 

Функциональность

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

В администраторской панели есть возможность управлять заказами и доступно управление несколькими платёжными сервисами

Как преимущества программного обеспечения официальный сайт отмечает следующие пункты

  • Открытость исходного кода.
  • Документированность ПО.
  • Неограниченность категорий, продуктов и их производителей.
  • Неограниченность информационных страниц.
  • Поддержка мультиязычности и перевода интерфейса.
  • Возможность устанавливать собственные темы.
  • Встроенные модули:
    • отзывы клиентов;
    • система рейтинга продуктов;
    • система изменения размера изображений;
    • система отображения сопутствующих продуктов;
    • система скидок и купонов;
    • система выбора способа доставки.
  • Возможность указать несколько налоговых ставок.
  • Возможность указать вес продукта без и с упаковкой и динамически рассчитываемая стоимость.
  • Поисковая оптимизация.
  • Неограниченная модульная система, для создания нескольких магазинов на одной платформе.
  • Инструменты резервного копирования и восстановления.
  • Отчёт об ошибках.
  • Регистрация ошибок.

Поисковая оптимизация

Официальный сайт сообщает, что поисковая оптимизация заключается в простановке мета-тегов

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

Сбор статистики

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

  • Отчёт о продажах. Считаются продажи за день, неделю и месяц.
  • Просмотры товаров. Полезно для отображения самых просматриваемых товаров.
  • Купленные продукты. Высчитываются самые продаваемые товары.

Мультиязычность

Официальный сайт утверждает, что система управления содержимым переведена с английского на 23 языках мира

  • Французский
  • Немецкий
  • Итальянский
  • Испанский
  • Русский
  • Китайский упрощенный
  • Традиционный китайский
  • Японский
  • Голландский
  • Венгерский
  • Индонезийский
  • Фарси
  • Норвежский
  • Португальский
  • Румынский
  • Турецкий
  • Польский
  • Украинский
  • Китайский

Итак, расскажу вначале о том, что больше всего понравилось в движке.

1. Самый большой, жирный плюс: хорошая, вменяемая реализация MVC. Такой нет у WordPress, Joomla, Drupal в принципе. Дальше боюсь соврать (поправьте, если что), но по-моему нет даже у Magento и Prestashop. Да-да, сейчас меня закидают, мол, нафига козе баян. Нужен, товарищи. Адекватная система разделения шаблона, контроллера и логики работы с данными — это залог успеха, удобства наращивания функционала на вашем проекте и вообще. Как говорится, если вы не любите кошек, вы просто не умеете их готовить. При этом у вас в папке с отображениями может лежать несколько шаблонов дизайна с возможностью выбора нужного в админке.

2. Удобная админка — ничего лишнего, но всё, что надо, есть. Вам не придётся вставлять css и шаблоны через админку (кто это придумал вообще, прекращайте курить). Не в последнюю очередь благодаря вещам из п.1 любой раздел можно крутить-вертеть-кастомить лёгким движением редактора (ну давай, расскажи мне, как ты кастомил админку в WordPress). Есть и легко прикручиваются/откручиваются фильтры и валидаторы по любым полям. Как следствие, не нужны даже сообщества — движок фактически является фреймворком в классических традициях с примерами для самого себя. К слову, сообщество у OpenCart довольно-таки немаленькое, так что единомышленников в случае чего будет найти вполне реально.

3. Из коробки есть ЧПУ (даже для вордпресса для этого нужно ставить расширение). Но если вы их не используете — то проект не заморочен тонной излишних реврайтов для работы базового функционала. Не знаю, кому как, но мне было приятно — всё же легче осваивать новый инструмент, когда логика путей прозрачна.

4. Заточенность под магазин делает доступными из коробки много нужных везде вещей: регистрация и личный кабинет, сложные формы с валидациями (для оформления заказа), фильтры и сортировку, отзывы, и т.д. Да, всё это есть из коробки или в модулях и для того же Yii, как и для любого другого фреймворка, но подкупает, когда всё уже реализовано, только чуть подпили напильником.

5. Приятная мелочь, важный момент для владельцев магазинов — много разных статусов заказа, и легко добавить новый.
Итого — хороший, быстрый движок, фактически являющийся гибридом классического фреймворка и классической CMS.

А теперь немного о минусах, которые пока что удалось заметить.

1. При хорошей классической MVC отсутствует какая-либо вменяемая реализация модели. Слои абстракции, ActiveRecord — это всё далеко от Опенкарта. Модели содержат простые запросы вида $this->db->query(«SELECT * FROM customer»).

2. Как бы не было много всего нужного в существующей начинке, в самый неподходящий момент оказывается, что чего-то критичного нет. Например, функции «обратный звонок». Или активация почты с помощью кода. И прочих мелочей, которые в принципе не так-то и сложно сделать, но погрязаешь в доработках, хотя кажется, что движок-то должен это уметь сам. Существует довольно много различных модулей для него (включая вышеописанные), но почти все из них платные, хотя цены обычно и не выходят из предела $10. Впрочем, я написал это сам, и теперь у меня этот функционал будет на последующие случаи.

3. Проблема, о которой писали на Тостере: движок сохраняет язык в cookies и не передаёт в ссылке, что ведёт к проблемам при обмене ссылками и создаёт помехи для SEO.

4. Процесс покупки довольно жёстко предопределён, при этом содержит много лишнего. Например, из коробки при оформлении заказа без регистрации у пользователя спросят адрес трижды: просто адрес, адрес доставки и платёжный адрес. Из трёх магазинов мне во всех трёх это пришлось убирать руками в куче мест. Другой пример — обязательное поле «модель» при создании товара. Ну нет у человека модели, бывает такое — приходится тоже руками убирать. Т.е., обобщая данный пункт — если вам надо выпилить что-то лишнее или добавить что-то новое, приходится делать очень много телодвижений в большом количестве мест кода.

netcatnetcat — утилита Unix, позволяющая устанавливать соединения TCP и UDP, принимать оттуда данные и передавать их. Несмотря на свою полезность и простоту, данная утилита не входит ни в какой стандарт (например, POSIX).

В составе модуля поставляются 5 компонетов (см. ниже). Для каждого компонента в структуре первого сайта автоматически создаются разделы. Если на одной копии системы работают несколько сайтов, для них тоже можно организовать каталоги ссылок, вручную создав разделы и добавив соответствующие компоненты в созданные разделы.

Изначально раздел «Ссылки» выключен, в нем содержатся несколько подразделов. Они делятся на две группы: подразделы каталога (включены) и служебные разделы (выключены). Тематическими подразделами можно управлять при помощи стандартных инструментов NetCat – добавлять, удалять, изменять название, создавать подразделы 3, 4 уровня и т.д. Если вы создаете новый подраздел, добавьте в него компонент «Ссылки: каталог ссылок».

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

При добавлении ссылки модуль проверяет ее на соответствие условиям обмена (см. ниже – «Настройки модуля»). Если ссылка не удовлетворяет условиям, пользователю выводится предупреждение, если удовлетворяет – ссылка добавляется. Одновременно с добавлением посетителю и администратору отправляется письмо с информацией о добавленной ссылке (эту возможность можно отключить – см. «Настройки модуля»).

Проверка всех ссылок, расположенных в базе, может производиться как вручную, так и автоматически. По умолчанию проверка производится раз в сутки (периодичность можно изменить в разделе «Инструменты» – «Управление задачами» системы управления сайтами NetCat). В ходе выполнения проверки модуль «обходит» все страницы, на которых должны быть расположены ссылки, и в случае отсутствия «нашей» ссылки выключает/удаляет ссылку партнера или переводит ее в режим редиректа (см. – «Настройки модуля»). Если партнер не выполнял условия обмена (ссылка находилась в режиме редиректа или была выключена), но в ходе очередной проверки обнаружилось, что он стал их выполнять, ссылка переводится в обычный режим. При каждом изменении статуса ссылки партнеру высылается письмо (эта возможность можетбыть отключена).

Также в ходе проверки модуль отслеживает наличие купленных ссылок и выключает проданные ссылки (при окончании срока продажи).

На странице каталога ссылок доступны следующие возможности:

  • Просмотр списка ссылок как по категориям, так и в полном объеме
  • Поиск ссылок
  • Переход по подразделам каталога
  • Переход на страницы с условиями обмена и с кодами «наших» ссылок
  • Добавление ссылки

6UMI.CMS — коммерческая мультисайтовая система управления контентом, созданная командой российских разработчиков «Юмисофт». В массовую продажу поступила в 2007 году.

Удобство

Система управления сайтами UMI.CMS создана и продолжает совершенствоваться под лозунгом «Удобство для людей». Она интуитивно понятна, проста в освоении и удобна в использовании для разработчиков сайтов, владельцев сайтов и их пользователей.

Готовность к SEO

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

Интеграция с 1С

В UMI.CMS осуществлена полная интеграция с торговыми конфигурациями платформы «1С: Предприятие», обеспечивающая импорт-экспорт данных в двустороннем порядке.

Безопасность

UMI.CMS надежно защищена от хакеров. Аудитом безопасности занимаются специалисты из компании ONsec, известные способностью за несколько минут находить уязвимости в проактивных защитах известных программных продуктов.

Экономичность

Чем крупнее сайт и чем активнее он используется, тем выше расходы на его постоянную поддержку и обновление. Управление сайтом в UMI.CMS настолько продумано, что любая типовая операция требует сделать всего 3-4 клика мышью и занимает всего 5-10 секунд времени!

Производительность

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

Мультисайтовость

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

UMI.Mobile

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

UMI.Manager

UMI.Manager — это бесплатное мобильное приложение для интернет-магазинов на платформе UMI.CMS. Теперь вы можете быстро и удобно управлять заказами с любого смартфона или интернет-планшета, работающего под iOS или Android, и быть на связи с вашими клиентами в любое время, из любой точки мира, где доступен интернет.

Интеграция с сервисами

UMI.CMS интегрирована со множеством сервисов, среди них: 1С:Предприятие, Яндекс.Маркет, МойСклад, Яндекс.Деньги, RBK Money, ROBOKASSA, Деньги Online, PayOnline, PayAnyWay, AcquiroPay, ВКонтакте, Google Picasa, Почта России, Яндекс.Метрика и MegaIndex.

Шаблонизаторы

UMI.CMS изначально подошла к вопросу интеграции различных шаблонизаторов универсально. Разработчик может воспользоваться тремя шаблонизаторами, в зависимости от поставленной задачи, сложности проекта и собственных навыков.

Служба Заботы

Служба Заботы о клиентах и партнерах UMI.CMS — это намного больше, чем просто техподдержка. Это уникальный сервис на российском IT-рынке, благодаря которому работа c UMI.CMS становится еще комфортнее.

Современная архитектура

В UMI.CMS изначально заложены гибкость и масштабируемость. Архитектура системы позволяет использовать эффективный и современный подход к разработке. UMI.CMS может быть интегрирована с любыми сервисами на базе xml: Picasa, 1C, ReST, YandexML, RSS, Flash, Flex, Silverlight и т.д.
Все данные хранятся в виде объектов — других сущностей в системе нет. Сами объекты создаются по настраиваемым шаблонам, оперируя которыми, разработчик может легко определять структуру объектов и связывать их между собой.

Главные преимущества:

  • Представление данных в формате XML — четкое структурирование и наглядность
  • Объектно-ориентированная модель данных, управляемая шаблонами данных — унификация представления данных в системе
  • Технология XSLT — мощный и гибкий инструмент для работы с XML-данными. XSLT — это современная кросс-платформенная технология, а не собственный шаблонизатор CMS. Для создания типовых сайтов на UMI.CMS достаточно понимать принцип работы всего трех тегов (xsl:template, xsl:apply-templates, xsl:value-of)
  • Концепция REST — внутренние протоколы, позволяющие осуществлять любое взаимодействие с системой как с xml-сервисами.

Объекты системы в формате XML:

Основной особенностью UMI.CMS является то, что все данные хранятся в виде объектов. Все привычные понятия в системах управления контента, такие как: страницы, пользователи, баннеры, заказы, скидки, адреса доставки товаров, сами товары – всё это объекты в UMI.CMS. При этом структура объектов определяется универсальным образом при помощи понятия «типы данных». Типы данных – это шаблоны для создания объектов, которые определяют количество и тип «полей», в которых объекты, созданные по этим шаблонам, могут хранить информацию.
Оперируя шаблонами данных, разработчик легко может определять структуру объектов и тип информации, хранящийся в объектах, и связывать их между собой.

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

Преимущества подхода:

  • Легко освоить
  • Удобно пользоваться
  • Просто адаптировать под поставленные задачи

Сайт как набор XML-сервисов:

В этой идее содержится вся суть подхода к разработке сайта на UMI.CMS при помощи XSLT-шаблонизатора. Шаблонизатор в этом случае является инструментом для агрегации и для вывода в необходимом нам виде данных, поступающих в формате XML, а XSLT – язык, при помощи которого мы управляем оформлением вывода.

В основе реализации данного подхода лежат следующие возможности UMI.CMS:

  • Использование формата XML для представления любых данных системы
  • Использование системы REST-протоколов для доступа к XML-представлению любых данных (как внутренних данных системы, так и внешних)

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

Поведенческие технологии

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

ElggElgg — это свободное (Open Source) программное обеспечение, доступное под лицензией GPL 2.0, платформа для построения социальных сетей любого уровня и назначения — от небольших интранет-порталов компаний, образовательных учреждений до открытых интернет-сообществ (система управления содержимым, CMS). Написан на РНР, использует JavaScript и Ajax-технологии. Для хранения информации использует в качестве хранилища базу данных MySQL.

Основные возможности

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

  • Активность

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

  • Личные сообщения

Вы можете отправлять приватные, личные сообщения своим друзьям.

  • Уведомления

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

  • Стена

Вы можете писать общедоступные сообщения в профиле пользователя на стене (messageboard).

  • Микроблог (а-ля твиттер)

Микроблоги позволяют превратить Ваш сайт в персональный Twitter. Пользователи могут писать сообщения в микроблог через сайт или с помощью SMS. Вы можете отправлять сообщения из своего микроблога в Twitter, и наоборот — Elgg поддерживает тесную интеграцию с сервисом Twitter. Так Ваши друзья и коллеги будут в курсе всего, что происходит у Вас.

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

В Elgg 1.5 появились новые инструменты для блогеров со следующими полезными функциями: • Автосохранение • Категории • Переключатель переписки • Предварительный просмотр • Возможность вставлять изображения, музыку, видео и другие медиа

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

  • Фото-галерея

Подключение модуля удобной фото-галереи TidyPics расширит функционал вашей социальной сети.

  • Видео-галерея
  • Документы, страницы (с возможностью совместной работы)

Плагин Pages позволяет хранить иерархически-организованные страницы с текстом, а также устанавливать, кто может читать и писать их. Это означает, что Вы можете совместно с друзьями и коллегами создавать документы, участвовать в процессе написания или просто писать страницу, видеть которую можете только Вы, и показать её миру лишь когда она будет готова.

  • Внешние страницы

Внешние страницы — это простой способ для администраторов сайта заполнить обязательные страницы «О сайте», «Правила» и «Конфиденциальность». При использовании с плагином Custom Index можно легко добавлять информацию на главную страницу из легкоуправляемого редактора WYSIWYG.

  • Вставка медиа

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

  • Файлы

Elgg оснащена полноценным файлохранилищем, который поддерживает широкий спектр форматов файлов, включая фотографии, документы Word, аудиозаписи, видео, PDF и другие. Вы можете быстро переключаться между списками файлов и галереями, чтобы быстрее найти то, что Вам нужно. Пользователи могут демонстрировать свои последние файлы в их профиле и, — используя вставку медиа, — добавлять любой файл в тексты.

  • Панель информации

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

  • Категории

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

  • Доступ

Elgg всегда предоставляла мощный контроль доступа для пользователей. В Elgg 1.5 появились два нововведения. Теперь пользователи могут ограничивать доступ к их информации. Кроме того, установки доступа по умолчанию теперь подконтрольны администратору сайта.