Joomla 3. Що нового для розробників. Теоретична частина.

Written by | 01 June 2013 | Published in 2013 June
В першій частині я розповів про практичні аспекти створення та адаптації розширень для Joomla 3. Мабуть ви помітили, що в ній не було нічого принципово нового. Річ у тім, що Joomla 3 настільки нова, що навіть її вдудовані розширення працюють в режимі сумісності з Joomla 2.5. Цього разу мова піде про справді нове. Настільки нове, що поки що немає зразків, щоб подивитися, як же це використовувати на практиці.

Нова концепія MVC

Зміни в концепції MVC настільки суттєві, що, як було сказано в попередній частині, жоден із вбудованих компонентів її поки що не використовує.

Причин для змін є дві:

  • відокремлення фреймворку від CMS
  • відмова від домовленності про те, що всі дані зберігаються в базі даних, а на виході HTML

Перше означає, що фреймворк може використовуватися самостійно, без CMS, і з його допомогою можуть створюватися й інші аплакації. Друге, що Joomla може використовуватися для створення не лише веб-сайтів, а й різноманітних сервісів які можуть видавати дані у різних форматах.

В новій Joomla 3 класи JController, JModel та JView більше не є класами, тепер це лише інтерфейси. Базовими класами є JModelBase , JViewBase і JControllerBase. І вони стали значно простішими. Тепер в них немає ніякої магії, все що повинно бути виконано, повинно бути вказано явно.
Зате добавили іншу магію — тепер не потрібно всюди вставляти функцію jimport. В Joomla 3 реалізовано автозавантаження класів, і в більшості випадків вона сама підвантажує потрібні класи коли це необхідно.

Нові котролери стали однозадачними. Тобто один котролер виконує лише одну задачу, на відміну від багатозадачних конролерів, які виконували кілька різних задач. У видах більше немає магічних методів — робота з моделлю здійснюється зверненням безпосередньо до моделі. А сама базова модель може лише утримувати стан.

Розширені класи JModelAdmin , JModelForm , JModelItem і JModelList є частиною пакету сумісності. В документації сказано, що більшість їхніх фукнцій доступні в новому API, однак мені не вдалося їх виявити. Ймовірно вони ще не раелізовані, і їх слід очікувати в наступних версіях.

Контролер

Базовим класом для контролерів є JControllerBase (хоча при необхідності можна наслідувати лише інтерфейс JController).

Кожен конролер виконує лише одну задачу, таку як: зберегти, видалити, показати і т.п. Для цього в котролері реалізовується метод execute. Сам конролен іменується по задачі, яку він виконує. Однак кожен котролер і навіть модель можуть викликати виконання інших котролерів, таким чином реалізуючи концепцію HMVC. Власне цим розробники і пояснюють однозадачність — легкі контролери без зайвого функціоналу викликають один одного і таким чином формують потрібний фукнціонал.

Якщо ви все ж віддаєте перевагу багатозадачним контролерам, то можете реалізувати її всередині методу execute. Але такий підхід не рекомендується.
Окрім того, тепер в контролері немає ні редиректів ні магічного запуску методу display зв’язаного з ним виду. Тобто, всі дії повинні бути вказані явно. З одного боку це вимагає писати більше коду, з іншого він стає зрозумілішім, і для реалізації обробки AJAX-запитів тепер не потрібно в кінці примусово закривати аплікацію, щоб вона не добавила ще й власний код.

class MyController extends JControllerBase
{
    public function execute()
    {
        $model = new MyModel();
        $paths = new SplPriorityQueue;
        $paths->insert(JPATH_BASE.'/view/item/tmpl', 1);
        $view = new MyView($model, $paths);    
        return $view->render();
        // Для AJAX останній рядок можна замінити на:
        // return json_encode($model->getItems());
    }
}

Модель

Інтерфейс JModel вимагає щоб класс реалізував методи getState і setState. Базовим класом для моделей є JModelBase. При створенні екземляру цього классу в конструктор може передаватися його стан в об’єкті JRegistry, інакше для завантаження стану буде виклакано метод loadState.

Як бачите, базова модель теж дуже проста. Ніяких методів роботи з базою даних чи ще чогось. Все, що вона може — зберегти стан і видати стан. Це дозволяє створювати моделі які зберігатимуть і отримуватимуть дані не лише з бази даних, а й з будь яких інших джерел, наприклад зовнішніх сервісів.

/**
* Модель без використання бази даних
*/
class MyModel extends JModelBase
{
public function getTime()
{
return time();
}
}

Однак, звичайно, фреймворк не був би повноціним, якби не забезпечував роботу з СУБД. Тому він містить і розширену базову модель JModelDatabase. Єдиною відмінністю від базового класу є наявність в ній властивості db, що містить об’єкт JDatabaseDriverDriver. Він дозволяє працювати з базою даних. Насправді, це той же JDatabase. Тепер він підтримує кілька різних СУБД.

Робота з таблицями не зміналася. Клас JTable з його похідними перекочува з попередньої версії без суттєвих змін.

/**
* Модель що використовує базу даних
*/
class MyModel extends JModelDatabase
{
public function getItems()
{
$q = $this->db->getQuery(true);
$q->select('*')->from($q->qn('#__mytable'));
$this->db->setQuery($q);

return $this->db->loadResult();
}
}

Вид

Інтерфейс JView вимагає наявності лише методів escape і render. Базовий клас містить в собі модель, яка повинна бути передана при ініціалізації. Тобто нічого для шаблонізації чи чогось подібного тут немає. Розробник повинен сам вирішувати яким чином і в якому вигляді дані потраплять на вивід. Це, знову ж таки зручно при обробці AJAX-запитів та реалізації інших сервісів.

/**
* Вид для виводу JSON
*/
class MyJsonView extends JViewBase
{
public function render()
{
$data = array(
'items' => $this->model->getItems()
);
return json_encode($data);
}
}

Якщо ж на виході повинен бути класичний html, то для цього існує клас JViewHtml. Цей клас реалізує метод render, в якому реалізована робота з шаблонами. Насправді реалізація дуже просто, файл шаблону викликається в контексті виду. Тому для передачі даних з виду у шаблон нічого не потрібно робити — все що доступно у виді, доступне і в шаблоні. Тобто в шаблоні можна звертатися до всіх методів і властивостей виду.

Згідно нового стандарту файли видів повинні іменуватися html.php, xml.php і т.д.

З неприємностей, у вид необхідно самостійно передати перелік шляхів, по котрим потрібно шукати шаблони.

Застосування нової MVC

Як було сказано вище, сама Joomla CMS поки що не використовує нову версію фреймворку і MVC. Розробники обіцяють повністю перейти на нього за рік-два. Цілком ймовірно, що у CMS описані вище класи будуть розширені до більш функціональних.

Мені вдалося знайти леши один навчально-експерементальний проект, який використовую нову MVC - Lendr (eng.)

Нові корисні бібліотеки

Серед цікавих новводень бібліотека Google для роботи з Google API. Тр можна без особливиз зусиль, наприклад, створити новий календар в Google, новий альбом в Picasa, чи організувати взаємодію з Google+. Ну і звичайно є клас для роботи з Google Maps.

Також добавлено клієнт для протоколу OAuth2. Що означає, що ви можете організувати взаємодію з більшістю сучасних сервісів. Серед них ВКонтакті, Однокласники, Facebook. Готової підтримки цих сервісів немає, але протокол дозволяє її огранізувати.

Чого чекати в майбутньому

На даний момент ведуться роботи над Joomla Framework — це, певною мірою, наступне покоління Joomla Platform. Осноними відмінностями є простір імен і встановлення за допомогою Composer. Назви цих фреймворків добре відображають суть. Joomla Platform — платформа Joomla, основа для CMS Joomla. Теоретично, вона дозволяє створювати інші аплікації, але фактично є лише 3, Joomla Installer і дві складові CMS: Joomla Administrator та Joomla Site. Joomla Framework — це подальше відокремлення фреймворку у самостійний проект. Він передбачає відхід від моноліту і побудову фреймворку на окремих компонентах.

Однак це не означає зникнення Joomla Platform. Цього року планується вихід версії Joomla Platform 13. Більше того, в найближчих версіях Joomla CMS ми не побачимо Joomla Framework, її поточна архітектура не готова до переходу. В ній все ще буде використовуватися і розвиватися Joomla Platform.
Такі перетасовки здаються дивними, але насправді все логічно — складно одночасно випускати фрейморк і продукт на ньому побудований. Тому й буде спочатку виходити фреймворк, а вже потім побудована на ньому CMS.

Read 8738 times Tagged under Ukrainian