Недоліки view в code igniter, tarlyun blog

Ні для кого не секрет, що CodeIgniter використовує концепцію MVC (Model-View-Controller). View або Подання - відповідає за відображення даних користувачеві. Головною перевагою концепції MVC є поділ логіки управління додатки, отримання даних і їх відображення. Починаючи працювати з CodeIgniter. ви йдете від мішанини з HTML / PHP / SQL в одному місці (мені до сих пір зустрічаються файли-модулі на 5000-7000 рядків з пекельними функціями в пару тисяч рядків). Працюючи з View. ви не повинні звертатися до моделей безпосередньо. Це повинно бути аксіомою для вас. Все що ви можете у View - це обробити вхідні дані з контролера і використовувати helper 'и.

Давайте подивимося недоліки базової реалізації View. Для прикладу візьмемо шматочок з документації: CodeIgniter> User Guide> Views

У більшості випадків ми ділимо шаблон на 3 частини: контент (який змінюється в залежності від сторінки), все, що до нього (header, заголовки, меню, шапка і т. Д.) І все, що після нього (footer, підвал, меню, контакти і т д).

Меню, звичайно, потрібно отримати з бази даних. Це робиться приблизно так:

Не самий елегантний і красивий метод. Для чого ми прийшли до CodeIgniter. Щоб навести порядок в своєму коді і піти від мішанини з SQL / PHP / HTML. А в підсумку до цього і повернулися.

2. Розширення базового контролера.

Шлях по якому я пішов 3 роки тому, коли вивчав CodeIgniter. Суть методу полягає у винесенні повторюваного шматка коду в один метод базового контролера, який і буде відповідати за отрисовку сторінки. Всі контролери будуть успадковуватися від одного базового. А для відображення View ми будемо користуватися новим методом _render.

Розберемо по порядку. Конструкція: final public function _render:

final - не дає перевизначити метод _render в нащадках класу MY_Controller. Це захист від випадкової зміни. Якщо раптом треба створити інший базовий шаблон, то можна створити новий метод: _render_ajax (), _render_admin () і так далі.

public - робить метод доступним поза класом.

_render - нижнє підкреслення перед ім'ям методу дозволяє створити захищений метод CodeIgniter. який не можна викликати в браузері.

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

У наступній частині ми зробимо огляд готових рішень для більш легкого і витонченого управління View.

Подивіться в сторону: $ this-> load-> vars ($ data);
Це зробить $ data доступним з усіх view завантажуються без вказівки переданих даних.
Перед цим робіть $ data [ 'content_view'] = 'some / name »;
і сміливо завжди викликайте одну і ту ж view, припустимо main.
всередині main пишіть
$ This-> load-> view ( 'header');
$ This-> load-> view ($ content_view) ';
$ This-> load-> view ( 'footer');

Готується друга частина, в якій буде огляд бібліотек-шаблонизатор під Code Igniter

Уже чотири місяці освоюю codeigniter. До всіх вищеописаних методів дійшов сам. Радий що це поширена практика. Дякую за статтю =)

Так, так і є, версія 2.1.3. Бібліотеку скачав, установив, CodeIgniter-Layout (sparks), але як їй користуватися не розумію і для чого вона по суті потрібна теж не до кінця ясно. Для мене стоїть тільки одне завдання, позбутися від одних і тих же записів типу:
$ Data [ 'pages'] = $ this-> pages_model-> get_pages ();
$ Data [ 'pages_info'] = $ this-> pages_model-> get_pages_info ($ title);
$ Data [ 'category'] = $ this-> pages_model-> get_category ($ title);
у всіх функції контролера. Проблему з шаблонами я вже давно вирішив, в плані завантаження видів. Залишилося тільки така проблема з видами. Як я розумію, можна піти шляхом того, що якимось чином передати властивості методів одного класу в інший клас, як в даному випадку в вашому прикладі. Але як це реалізувати до кінця незрозуміло. А часу немає, щоб за кілька місяців або по пів року сидіти вивчати якісь бібліотеки для незрозумілих шаблонів, які в подальшому можливо і не знадобляться мені на практиці.

Для мене стоїть тільки одне завдання, позбутися від одних і тих же записів типу

Зробіть в базовому контролері властивість $ data
У конструкторі контролерів робите присвоювання:
$ This-> data [ 'pages'] = $ this-> pages_model-> get_pages ();
$ This-> data [ 'pages_info'] = $ this-> pages_model-> get_pages_info ($ title);
$ This-> data [ 'category'] = $ this-> pages_model-> get_category ($ title);

І передавайте замість $ data $ this-> data в шаблон.

Трохи не зрозумів, Зробіть в базовому контролері властивість $ data. Це властивість робити в MY_Controller і потім наслідувати в інших контролерах клас з цією властивістю? І як зробити це властивість? Адже властивість має бути природною якогось об'єкту. А якщо не створювати об'єкт, то як створити властивість. Поясніть будь ласка.